Cómo construir una matriz de datos para decidir qué modelo puede recibir cada tipo de información

Primero inventaría pocas clases de datos, no cincuenta. Empieza con cuatro o cinco niveles que el equipo pueda aplicar de manera consistente: público, interno, confidencial, regulado y secreto crítico, por ejemplo. Define ejemplos concretos para cada uno y quién puede cambiar la clasificación. Evita categorías que dependen de intuición. Un mismo archivo puede contener varias clases; en ese caso adopta la más restrictiva o divide el contenido antes de procesarlo. La matriz solo funcionará si la persona y el sistema pueden reconocer qué etiqueta corresponde sin una discusión nueva en cada ejecución.

Después define atributos de proveedor verificables. Para cada modelo o servicio registra retención máxima, uso o no para entrenamiento, región disponible, cifrado, controles de empresa, subprocesadores relevantes y si ofrece configuraciones como zero-data-retention. Guarda también la fuente y la fecha de cada dato porque los términos cambian. No conviertas marketing en garantía técnica. Si un atributo no está confirmado, trátalo como desconocido y decide si esa incertidumbre lo vuelve inelegible para categorías sensibles.

Cruza clases y proveedores con reglas simples. Una fila puede decir que datos públicos permiten cualquier proveedor aprobado; confidenciales requieren no entrenamiento y retención limitada; regulados exigen región y contrato específicos; secretos críticos solo usan infraestructura interna. La salida de la matriz debe ser una lista de proveedores elegibles, no uno fijo. Así el orquestador conserva flexibilidad para optimizar costo, latencia o calidad dentro del conjunto permitido. Cuando cambie una política, actualizas una tabla y vuelves a probar rutas.

Añade requisitos de minimización por tarea. Incluso si un proveedor es elegible, la habilidad debería enviar solo los campos necesarios. Documenta qué datos necesita cada operación y qué transformaciones puede hacer antes: recortar secciones, reemplazar identificadores, resumir o extraer atributos. Define también qué transformaciones no sirven. Por ejemplo, borrar el nombre de una propuesta comercial puede no anonimizarla si el proyecto y las cifras la identifican. La matriz debe combinar quién puede recibir datos con cuánto necesita recibir.

Implementa un preflight de routing. Antes de invocar un modelo externo, el runtime recibe clasificación del artefacto, requisitos de la habilidad y atributos actualizados del proveedor. Si existe una ruta compatible, la selecciona y registra la decisión. Si no existe, no improvisa. Puede pedir al usuario una versión redactada, usar un modelo local o detener la tarea con una explicación precisa. El preflight ocurre antes de transmitir contexto; comprobar la política después de la llamada solo sirve para documentar una exposición que ya sucedió.

Registra metadatos, no copias del secreto. El audit log puede guardar dataClass, proveedor, modelo, política, transformaciones, campos transmitidos y resultado del preflight. Evita replicar payloads sensibles salvo que exista una necesidad separada y una política para ello. Esta práctica permite demostrar qué ruta se tomó sin crear un almacén alterno difícil de proteger. Incluye un identificador del artefacto y, cuando convenga, un hash para confirmar que la clasificación se aplicó a la versión correcta.

Convierte cambios contractuales en tests automáticos. Mantén casos representativos por clase y habilidad. Cuando cambie la retención de un proveedor, su región o una política interna, ejecuta la suite y observa qué rutas dejan de ser elegibles. Genera una lista de habilidades afectadas antes de desplegar el cambio. Una matriz útil no es una hoja estática para compliance; es una dependencia viva del producto. Si el sistema puede reaccionar a términos nuevos sin revisar manualmente cada agente, la privacidad se vuelve parte de la arquitectura y no una promesa frágil.