La seguridad de IA se vuelve imposible de operar cuando scanners, filtros de prompt, red-team tools, catálogos, IAM, logs, reviews de proveedores y hojas de cálculo describen fragmentos distintos del mismo sistema sin identidad compartida.
NIST AI RMF incluye Govern, Map, Measure y Manage y pide mecanismos para inventariar sistemas de IA. Un inventario útil no termina en “modelo y owner”. Conecta caso de uso, owner, modelo y provider, versiones de prompt, datos, agentes, tools, identidades, permisos, deployments, evaluaciones, incidentes y requisitos aplicables.
Sin relaciones, cada herramienta produce findings huérfanos. Una alerta de prompt injection vale poco si la plataforma no responde qué agente usó el prompt, qué datos podía leer, qué tools llamaba, qué tenants fueron afectados y dónde existe la misma configuración.
Las hojas documentan política. Gateways bloquean calls. Red-team tools encuentran fallas. Un control plane conecta todo: risk tier determina evaluaciones; resultados deciden release; política de deployment define modelos, datos y tools; evidencia runtime prueba si las restricciones se mantuvieron.
NIST AI RMF Playbook enfatiza políticas transparentes, roles, documentación y riesgo continuo. Generative AI Profile agrega acciones para riesgos únicos o amplificados. La plataforma debe convertir outcomes en controles técnicos y evidencias reutilizables.
MITRE ATLAS ofrece una base viva de tácticas y técnicas contra sistemas de IA. OWASP GenAI Security Project y AI Exchange ofrecen orientación práctica. El control plane debe mapear findings, evaluaciones, detecciones y mitigations a una taxonomía común para revelar si existen controles solo para prompt injection mientras model theft, data poisoning, excessive agency, supply chain y divulgación quedan descubiertos.
La cobertura también necesita contexto arquitectónico. El mismo modelo puede ser bajo riesgo en resumen interno y alto riesgo conectado a datos de clientes y tools financieras. La postura pertenece al sistema desplegado, no solo al artefacto.
| Capacidad | Pregunta respondida | Evidencia recolectada | Acción habilitada |
|---|---|---|---|
| Inventario de IA | ¿Qué existe, dónde, por qué y quién responde? | Casos, modelos, prompts, datos, tools, owners, vendors y deployments. | Descubrir shadow AI, asignar tier y aplicar gates. |
| Mapeo de datos | ¿Qué datos sensibles entran, salen o entrenan? | Fuentes, clases, retrievals, destinos, retención y regiones. | Bloquear flujos, minimizar datos y evaluar exposición. |
| Grafo de identidad | ¿Quién llama modelos, datos, agentes y tools? | Principals, agentes, scopes, delegación, secrets y permisos. | Aplicar least privilege, revocar y reconstruir acciones. |
| Registro de evaluaciones | ¿Qué riesgos fueron probados para este release? | Datasets, ataques, métricas, thresholds, findings y regresiones. | Bloquear release, comparar versiones y exigir remediación. |
| Política y telemetría runtime | ¿El comportamiento quedó dentro de límites? | Prompts, outputs, retrieval, tools, decisiones, costos e incidentes. | Detectar, contener, investigar y ajustar controles. |
| Riesgo de vendor y modelo | ¿Qué terceros afectan seguridad, privacidad y resiliencia? | Términos, regiones, entrenamiento, retención, attestations, cambios e incidentes. | Aprobar, restringir, monitorear, sustituir o salir. |
La plataforma no necesita reemplazar cada herramienta especialista. Debe normalizar identidades, findings, políticas y evidencias para scanners, gateways, SIEM, catálogos, IAM, evaluaciones y tickets cooperar. Las herramientas siguen útiles; el control plane vuelve outputs comparables y accionables.
Tampoco puede ser dashboard pasivo. Controles de alta confianza deben aplicar modelos aprobados, clases de datos, permisos de tools, release gates, logging y vencimiento de excepciones. Riesgos de menor confianza crean reviews, pruebas o investigaciones.
Construiría un grafo de sistemas de IA como source of truth, con adapters que descubren endpoints, prompts, vector stores, agentes, tools, IAM, evaluaciones y telemetría. Las políticas se unirían a relaciones del grafo y producirían controles preventivos y requisitos de evidencia.
La vista principal comenzaría en cualquier feature y revelaría owner, tier, modelo, vendor, data flows, permisos, pruebas, versiones, excepciones, incidentes, costos y findings. Otra vista comenzaría en un riesgo o proveedor y mostraría todos los sistemas afectados.
La seguridad de IA no es un scanner en la frontera del modelo. Es control continuo sobre modelos, datos, identidades, prompts, tools, proveedores y decisiones humanas. El control plane funciona cuando gobernanza alcanza runtime y evidencia runtime cambia gobernanza.
Artículo sobre plataformas y control planes de seguridad de IA cubriendo inventario, prompts, data flows, identidades, permisos, evaluaciones, logs, riesgo de proveedores, gobernanza y MITRE ATLAS.