Noticias, guías y análisis
La retención de datos ya no puede vivir en una política de privacidad: debe convertirse en una variable que el orquestador entienda
Análisis sobre cómo convertir retención, residencia, entrenamiento y sensibilidad de datos en atributos operativos que controlan qué proveedor o herramienta puede recibir contexto.
Las políticas de privacidad suelen describir lo que ocurre después del diseño. Enumeran categorías de datos, fines, terceros y periodos de retención. En un sistema agentic, esa información necesita entrar al diseño antes de ejecutar porque el agente puede decidir dinámicamente qué modelo, herramienta o subproceso usar. Si la política solo existe en un documento legal, el orquestador no puede aplicarla. La arquitectura necesita una representación legible por máquina: sensibilidad, ubicación permitida, retención máxima, uso para entrenamiento, requisitos de cifrado y restricciones de proveedor.
La clasificación debe viajar con el dato. Un documento no deja de ser confidencial porque un agente extrajo tres párrafos. La etiqueta de sensibilidad debería heredarse o recalcularse en cada transformación. Algunas operaciones reducen riesgo, otras lo mantienen y algunas lo aumentan al combinar fuentes. El orquestador necesita reglas para esa propagación. Sin ellas, un subagente puede recibir un resumen aparentemente inocuo que todavía contiene secretos comerciales. El objetivo no es etiquetar por burocracia, sino impedir que una transformación rompa silenciosamente la política que protegía el material original.
La selección de proveedor se vuelve una consulta de elegibilidad. En vez de codificar “usa modelo X” dentro de cada habilidad, el workflow puede solicitar una capacidad: razonamiento largo, visión, código o baja latencia. Una capa de policy routing filtra proveedores según las restricciones del contexto y después optimiza costo o rendimiento entre los permitidos. Así una actualización contractual de retención cambia una configuración central y no decenas de agentes. También permite tener una respuesta segura cuando ningún proveedor externo cumple: usar una ruta local, degradar funcionalidad o pedir al usuario una alternativa.
La minimización necesita ser específica para la tarea. Enviar menos datos es una buena regla, pero no basta con cortar texto arbitrariamente. Cada herramienta debería declarar qué campos necesita para producir un resultado válido. Un agente que agenda una cita puede requerir nombre, zona horaria y disponibilidad, pero no el historial completo de conversación. Un analizador de contrato quizá necesite cláusulas específicas y jurisdicción, no el repositorio entero. Diseñar contratos de entrada mínimos reduce exposición y hace más fácil auditar por qué una información salió del sistema.
Las decisiones de privacidad deben quedar registradas sin duplicar el secreto. Un log útil no necesita almacenar todo el payload sensible. Puede guardar clasificación, proveedor, versión de política, campos enviados, transformaciones aplicadas y resultado de elegibilidad. Esto permite reconstruir si una ruta fue autorizada sin crear un segundo almacén lleno de datos privados. La observabilidad responsable distingue evidencia de contenido. El sistema registra lo suficiente para demostrar cumplimiento y depurar errores, pero evita que el mecanismo de auditoría se convierta en una nueva superficie de filtración.
Los cambios de política necesitan regresión igual que los cambios de código. Si un proveedor modifica términos o una empresa endurece sus reglas internas, debemos saber qué habilidades quedan afectadas. Una matriz de dependencias permite ejecutar pruebas que simulan datos de distintas clases y comprueban el routing esperado. Esto previene un fallo común: actualizar la política escrita mientras automatizaciones antiguas continúan enviando información por rutas que ya no cumplen. La gobernanza se vuelve operativa cuando una modificación produce tests, alertas y cambios de elegibilidad medibles.
Aplicación Goatify. Podemos tratar dataPolicy como parte del contrato de cada ejecución. Una habilidad declararía qué datos necesita y qué transformaciones produce; cada artefacto conservaría clasificación; el router elegiría proveedores compatibles; el log registraría la decisión sin copiar material sensible. Esto nos permitiría ofrecer a clientes empresariales una respuesta concreta a “¿dónde viajan mis datos?”. No sería una promesa general de privacidad, sino un mapa verificable de rutas permitidas y una garantía técnica de que las no permitidas no llegan a invocarse.