Esta nota es contexto; el trabajo actual son los paquetes Web & eCommerce y la entrada US → EMEA.
La mayoría de los programas de agentes no muere en el laboratorio. Muere después del lanzamiento.
La investigación AI Production Paradox de Sinch (mayo 2026, n=2.527 directivos, 10 países) encontró que el 74% de las empresas retiró o apagó un agente de comunicaciones con clientes ya desplegado tras un fallo de gobernanza — no un piloto parado, un sistema en vivo retirado. Entre quienes describían sus guardarraíles como plenamente maduros, la tasa de retirada fue mayor: 81%.
Es investigación pagada por un proveedor, así que tratad las cifras absolutas como dirección, no como marcador. Y la dirección es lo que importa: el segundo número no dice que los equipos maduros sean peores, dice que ven más. Detectan los incidentes que otros nunca notan y descubren que el control que compraron puntúa prompts en lugar de filtrar filas.
Las causas principales lo confirman: exposición de PII o datos de cliente (31%), alucinación o riesgo de marca (22%) y falta de auditoría — no poder diagnosticar qué ocurrió (16%) (capítulo Sinch). Ninguna de las tres se arregla con un modelo más listo. Las tres se deciden en la frontera donde las herramientas del agente tocan vuestros datos.
A esa frontera la llamamos el Perímetro de Producción.
La segunda idea de este artículo es operativa: el tiempo a producción es el tiempo a los datos correctos. Publicar un agente que ve todo no es más rápido que publicar uno que ve las filas adecuadas. Solo lo parece hasta la retirada.
La producción es una puerta de gobernanza, no de capacidad
El discurso del fracaso sigue tratando a los agentes como compra de capacidad: elige un modelo frontier, conecta herramientas, publica. Nuestra autopsia del fracaso agéntico nombra el patrón real Crisis del Alcance — fallan la gestión y el alcance antes que el modelo. Este artículo es el complemento: qué hay que aplicar en la costura de datos cuando el alcance ya es lo bastante estrecho para publicar.
Tres verdades que se aprenden en las retiradas:
- Los agentes heredan rutas de acceso. Una cuenta de servicio con admin del warehouse no se vuelve más segura porque encima haya un modelo de lenguaje. Se vuelve más rápida leyendo — y filtrando — lo que esa cuenta ya podía ver.
- «¿Qué vio?» es una pregunta de datos. Reguladores, seguridad y vuestra propia revisión de incidente piden linaje y auditoría — qué tablas, qué filas, qué chunks — no solo la respuesta en lenguaje natural.
- Observar sin aplicar es herramienta de post-mortem. Trazas que registran una fuga después de 10.000 filas no son gobernanza. El primer Magic Quadrant de plataformas de gobernanza de IA de Gartner (junio 2026) ponderó la intervención en runtime — ¿podéis cortar una violación en ruta? — por encima de las carpetas de política. Ese listón vale para un agente que consulta Snowflake, no solo para un chatbot de atención.
Los modelos bastan para flujos estrechos. El acceso, la auditoría y el control de deriva, no.
Un fallo concreto: el agente que vio el tenant equivocado
Imaginad un agente de soporte con una herramienta SQL sobre tickets. El demo usaba una vista filtrada. En producción la misma herramienta apuntó a la tabla cruda con una cuenta de servicio compartida. El modelo hizo lo que hacen los modelos: respondió con el contexto más rico que pudo recuperar — incluidos tickets de otro tenant, otro país, otra entidad jurídica.
Nada «alucinó». El modelo fue preciso sobre datos que nunca debió ver. No hizo falta inyección de prompt. Un cortafuegos de prompts podría haber bloqueado un jailbreak; no habría aplicado el filtro de fila que el warehouse ya sabía aplicar a analistas humanos.
Eso es el Perímetro de Producción en un incidente: el agente es un principal nuevo en rutas de datos viejas. Si esas rutas nunca fueron granulares, el agente hereda el agujero a velocidad de máquina.
Dibujado, el perímetro son tres puertas en la ruta de la petición — y un atajo muy común que las rodea.
Desliza para ver el diagrama completo
Tres preguntas contrastan cualquier arquitectura con ese dibujo:
- ¿Quién pregunta? No «qué aplicación» — qué principal con nombre, para qué propósito declarado, con qué caducidad.
- ¿Qué puede hacer la herramienta? Qué campos, qué operaciones, qué límite de tasa — escrito, no implícito en una cadena de conexión.
- ¿Qué filas vuelven? Si la cuenta de servicio del agente puede devolver una fila que un humano con ese mismo trabajo no vería, no tenéis perímetro. Tenéis un log.
Dos olas de proveedores — y por qué no son intercambiables
El mercado se ha ordenado en dos olas. Es útil, no tribal. Compráis la ola equivocada para vuestro modo de fallo y seguiréis retirando.
Ola A — Seguridad de agentes y LLM (nueva, con forma de prompt)
Estas empresas son, en gran parte, nuevas. Crecieron con la primera ola generativa: inyección de prompt, jailbreaks, salida tóxica, fugas en el prompt, red team antes de lanzar. Son necesarias. No bastan para agentes de producción con herramientas.
| Proveedor | Cuña | En qué es fuerte |
|---|---|---|
| Lakera | Plataforma de seguridad nativa de IA | Prevención de ataques a prompts en runtime, descubrimiento de IA en plantilla, guardarraíles de baja latencia |
| Preamble | Evaluaciones independientes de seguridad de IA | Red team de agentes, abuso de herramientas, liderazgo fraccional para despliegues regulados |
| Guardrails AI | Biblioteca abierta de guardarraíles | Validación de salida, ganchos de política en código |
| NVIDIA NeMo Guardrails | Rails programables | Restricciones de diálogo y de llamadas a herramientas en stacks NeMo |
La ola A responde: «¿Fue seguro este prompt o esta respuesta?» No responde sola: «¿Debe esta identidad de agente ejecutar SELECT * sobre clientes para este propósito declarado?»
Ola B — Gobernanza de acceso a datos (problema viejo, principal nuevo)
Estos proveedores crecieron con FGAC de warehouse y lakehouse, catálogo, enmascaramiento y política entre motores. Los agentes no inventaron ese problema; añadieron una clase de identidad no humana que golpea los mismos motores, más rápido, con peores historias de auditoría cuando algo falla.
| Proveedor / patrón | Cuña | En qué es fuerte |
|---|---|---|
| Controles nativos del motor | En plataformas que ya operáis | Políticas de fila/columna, linaje y gobernanza de IA en Unity Catalog; seguridad de columnas en Snowflake; filtros de Lake Formation |
| Apache Ranger | Plugins de política open source | Ganchos de aplicación en el motor (Hive, Trino y afines) |
| Plataformas de acceso entre motores (p. ej. Trust3 AI) | Política unificada + plano de control de agentes | El mismo FGAC lógico entre motores; acceso basado en propósito; descubrir/observar/asegurar entre agentes y datos |
| Suites de catálogo y derechos (Immuta, Collibra y pares) | Política y catálogo a escala | Acceso por atributos, clasificación, flujos de derechos |
La ola B responde: «Dada esta identidad de agente y este propósito, ¿qué datos puede tocar esta herramienta — y podemos demostrarlo?»
Por qué la ola B tiene ventaja estructural
No porque la ola A sea inútil — en producción a menudo hacen falta las dos. Porque los agentes operacionalizan el acceso:
| Pregunta dura de producción | Ola A (prompt / entrada en runtime) | Ola B (ADN de acceso a datos) |
|---|---|---|
| ¿Qué filas puede ver este agente? | No es su unidad de trabajo | FGAC: filtros de fila en el momento de la consulta |
| ¿Qué columnas entran en la ventana de contexto? | Puede redactar PII en texto después de recuperar | Enmascaramiento / cifrado antes de recuperar |
| ¿Qué fundamentó esta respuesta? | Traza del prompt / de la respuesta | Linaje de origen → tabla/chunk → resultado de herramienta |
| ¿La misma regla en Snowflake y Databricks y el lago? | Rara vez | Sincronización de política / plugin Ranger / constructos nativos |
| ¿Podemos cortar la consulta, no solo registrarla? | A veces, en el gateway LLM | Aplicación en runtime en el motor o en la capa de confianza |
- Linaje: Sin catálogo y linaje no reconstruís qué corpus de recuperación o qué resultado SQL fundamentó una respuesta. Unity Catalog sigue el flujo desde tablas origen hasta modelos y servicios; esa es la cadena de evidencia que pide un auditor cuando el agente cita mal un saldo.
- FGAC en el momento de la consulta: Un filtro de prompt no filtra filas. El acceso granular — filtros de fila, máscaras de columna, concesiones ligadas a un propósito — debe ejecutarse donde corre la consulta: plugin Ranger, política de Unity Catalog, masking de Snowflake, filtros de Lake Formation o una capa de política sincronizada. El patrón está documentado entre motores; la visión general de FGAC de Privacera es una descripción secundaria clara de plugin frente a nativo.
- MCP multiplica superficies: Cada servidor MCP es un contrato de herramienta más una ruta de datos. Asegurar prompts y dejar credenciales MCP con exceso de privilegio repite el patrón de retirada de Sinch con otro protocolo.
- Velocidad de máquina: Un analista que se equivoca de dashboard es un incidente. Un agente que itera herramientas es un incidente por lotes. La gobernanza «suficiente» para 50 consultas humanas al día se rompe a 5.000 autónomas.
Los proveedores de la ola A están añadiendo contexto de herramienta e identidad — con razón. Los de la ola B ya viven en el plano de aplicación que los equipos de datos pelearon con RGPD, HIPAA y SOX. El Perímetro de Producción es ese plano extendido a principales no humanos.
Por qué el ADN de gobernanza de datos es la ventaja estructural
Una startup de seguridad de IA empieza por el prompt. Una empresa de gobernanza de datos empieza por quién puede ver qué celda, en qué motor, con qué traza de auditoría. Para agentes, el segundo punto de partida es el caro de construir y el barato de tener ya.
Trust3 AI es una de las caras actuales de ese linaje — la misma organización que antes se llamó Privacera, con años de acceso granular entre motores antes de que «agéntico» fuera categoría. La citamos porque la arquitectura que documenta es la que necesitan los agentes en producción, no por ninguna relación comercial ni de reventa. Describimos un patrón documentado; verificadlo contra Unity Catalog, Snowflake, Ranger y Lake Formation en vuestro propio estate.
Tres razones estructurales de por qué ese ADN importa ahora:
1. La política entre motores ya era el problema difícil antes de los agentes. Los estates multi-nube ya necesitaban la misma regla lógica en Trino, Snowflake, Databricks y un lago. Los plugins Ranger interceptan la consulta dentro del motor; los enfoques de sincronización traducen la regla a constructos nativos (UDFs de masking, filtros de fila de Unity Catalog, filtros de Lake Formation). Los agentes no inventaron esa división. Aumentan el número de principales que golpean esos motores a la vez. Quien ya entrega esa capa de traducción no está aprendiendo FGAC en el camino crítico del cliente.
2. Observabilidad y autorización tienen que encontrarse en un plano de control. El posicionamiento público de esa plataforma — descubrir cada agente, observar cada decisión, asegurar cada acción en Copilot, Bedrock, Databricks Agent Bricks, MCP y builds a medida — deja claro que trazas y permisos deben unificarse en el momento de la acción, no en SKUs separados. El marco de Forrester de diciembre de 2025 sobre el plano de control de agentes (citado en ese sitio) describe una capa de aplicación fuera del plano de construcción. Compréis o no un producto, ese planteamiento es el test correcto para vuestra stack: ¿la política se sienta entre el agente y los datos, o solo en un dashboard después?
3. El propósito gana al cargo cuando el actor es una máquina. El RBAC humano («analista», «soporte nivel 2») encaja mal con identidades efímeras de agente y una tarea declarada. El acceso basado en propósito — qué puede hacer esta ejecución para este trabajo, acotado en el tiempo — es cómo se evitan claves de admin permanentes en cuentas de servicio. Concesiones JIT y ámbitos que caducan solos son la misma idea a la que ya apuntan motores nativos y el vocabulario PBAC. Las startups que solo puntúan prompts aún tienen que inventar identidad, propósito y caducidad. Las plataformas de acceso a datos ya viven ahí.
Lo que no afirmamos: que un único proveedor sea obligatorio, que la seguridad de prompts esté resuelta, o que un operador mid-market deba comprar un plano de control enterprise el día uno (véase nuestra Línea de Pobreza de Gobernanza). Sí afirmamos que los equipos con años de FGAC, catálogo y pistas de auditoría tienen un camino más corto a un Perímetro de Producción defendible que quienes empiezan solo con un cortafuegos de prompts. Esa es la ventaja. El resto es empaquetado.
Manual práctico — más rápido a producción y a los datos correctos
Cada paso tiene definición de hecho. Si saltáis uno, estáis montando un demo, no un compromiso operativo.
El truco de secuencia: no serialicéis «gobernar y luego publicar». Reducid la superficie de datos de un flujo en paralelo con el agente. Una lista blanca de recuperación y un principal de mínimo privilegio para ese flujo ganan a un programa de catálogo de doce meses que nunca se cruza con el piloto.
1. Inventariar identidades de agente como roles humanos
Hecho cuando: Cada agente en producción tiene un principal de servicio con nombre, un dueño, un propósito declarado y ninguna credencial de admin compartida. Cuenta la IA en la sombra: un copiloto de navegador con SSO al warehouse es un agente que vuestro perímetro no ve.
Criterio de aceptación: podéis listar identidades de agente en un inventario; cada una mapea a un aprobador; ninguna credencial sirve a la vez para ETL por lotes y para herramientas de cara al cliente.
Atajo de tiempo a producción: clonad el rol humano que ya hace el trabajo y quitadle escritura y exportación. No inventéis un rol nuevo de «admin de IA».
2. Contratar cada herramienta (MCP, SQL, API)
Hecho cuando: Cada herramienta documenta operaciones permitidas, listas blancas de campos, filtros de fila, límites de tasa y si hay escritura. «Leer CRM» no es un contrato; «leer contacts.email, contacts.tier para account_id en el alcance del llamante; sin exportar» sí.
La guía práctica de agentes de OpenAI recomienda maximizar las herramientas de un solo agente solo hasta que el solapamiento provoque mala selección — el diseño de herramientas es alcance.
Atajo: una herramienta de lectura y una de borrador antes de cualquier escritura. MCP no cambia ese orden.
3. Aplicar en ruta, no al lado
Hecho cuando: Una decisión de política (permitir, denegar, enmascarar, acotar) se ejecuta antes de que los datos vuelvan al contexto del modelo. Gateways (Portkey, Kong, LiteLLM con matices), plugins de motor (Ranger, Unity Catalog), filtros de Lake Formation o una capa de confianza unificada — elegid la costura que vuestra arquitectura ya cree.
Los sidecars solo-log sirven para depurar; no son un perímetro — es la ruta roja del diagrama del perímetro, más arriba.
Atajo: si la tabla ya tiene un filtro de fila humano, atad el principal del agente a ese filtro antes de escribir un lenguaje de política nuevo.
4. Etiquetar linaje en corpus RAG y consultas en vivo
Hecho cuando: Por cada respuesta de producción podéis señalar objetos origen: IDs de documento, nombres de tabla, versiones de chunk. Las entradas de catálogo ligan índices de recuperación a clasificación aguas arriba. Si la recuperación devuelve el chunk equivocado, un modelo más fuerte sigue mintiendo con confianza — nuestro artículo sobre datos listos para IA cubre la calidad de recuperación; el linaje cubre la rendición de cuentas.
Atajo a los datos correctos: un corpus en lista blanca para el flujo (carpetas nombradas, tablas etiquetadas) es más rápido que «embeber el disco compartido». Datos equivocados en el índice son un fallo de perímetro que parece alucinación.
5. Publicar evaluaciones antes de escalar — construidas con fallos del piloto
Hecho cuando: Un juego de evaluaciones versionado cubre camino feliz, rechazos y modos de fallo conocidos del piloto (mala clasificación, llamada de herramienta demasiado amplia, casi-fuga de PII). El State of Agent Engineering 2026 de LangChain (n=1.340) reporta 89% de adopción de observabilidad y solo 52% de evaluaciones sistemáticas — el hueco que convierte incidentes en incidentes repetidos.
Atajo: diez casos de evaluación de tickets reales ganan a cien sintéticos. Incluid dos casos «no debe ver» (otro tenant, columna enmascarada).
6. Vigilar la deriva del agente contra la línea base
Hecho cuando: Saltan alertas ante desviación material del comportamiento publicado: tablas nuevas en trazas, cardinalidad de herramientas al alza, cambios de permiso en cuentas de servicio, fuentes de recuperación fuera de catálogo. La deriva no es solo un cambio de versión de modelo — es crecimiento de alcance en producción.
Atajo: registrad tables_touched y tool_name desde el día uno. Los dashboards bonitos pueden esperar; no se reconstruye una primera semana sin log.
El bucle solo se cierra si la comparación es automática — línea base a un lado, trazas en vivo al otro y un responsable con nombre para la diferencia:
Desliza para ver el diagrama completo
7. Puerta humana en acciones irreversibles
Hecho cuando: Envío externo, escritura financiera, borrado y cambio de configuración de producción pausan hasta aprobación — no como pulido opcional de UX. El borrado de base de producción de Replit y la responsabilidad del chatbot de Air Canada aplican con independencia de la madurez del perímetro.
Atajo: publicad lectura-y-borrador a producción con envío humano. La autonomía es una versión posterior, no un requisito de lanzamiento.
Juntad los siete pasos y aparece la forma que repiten los agentes que sobreviven a su primer trimestre:
Desliza para ver el diagrama completo
Glosario — términos que usará vuestro auditor (y vuestro juego de evaluaciones)
Definiciones densas para revisiones de seguridad, cuestionarios de compra y motores de respuesta. Donde hay página propia, enlazamos.
Perímetro de Producción — Frontera aplicada donde las herramientas del agente encuentran los datos; la política corre en ruta antes de que filas o chunks entren en el contexto del modelo.
Tiempo a los datos correctos — Cuánto tarda un agente en quedar atado a las tablas, filas y documentos que puede usar. Distinto del tiempo al primer demo. La velocidad de producción es sobre todo esto, no la elección de modelo.
FGAC (control de acceso granular) — Restricciones por debajo de la tabla: filas, columnas, máscaras, cifrado. Documentado de forma nativa en cada motor: Unity Catalog, seguridad de columnas en Snowflake y filtros de Lake Formation.
OLAC (control a nivel de objeto) — Permisos de fichero, bucket u object store; necesario donde el FGAC SQL no bloquea el bypass directo al almacén de objetos.
RBAC / ABAC / TBAC — Acceso basado en roles, atributos y etiquetas. Los humanos suelen empezar en RBAC; los agentes suelen necesitar atributos o etiquetas (tenant, propósito, clase de dato) porque no tienen cargo.
PBAC (control de acceso basado en propósito) — El acceso se decide por el propósito declarado de la tarea, no por el cargo estático. Véase /es/glossary/pbac/.
Linaje de datos — Grafo demostrable desde el origen, por transformaciones, hasta el activo que el agente leyó o citó. Los catálogos lo automatizan cuando el agente usa conexiones gobernadas.
Catálogo de datos — Inventario de conjuntos, dueños, clasificaciones y (en lo ideal) políticas. Sin él, cada servidor MCP se convierte en un warehouse privado sin documentar.
Clasificación / etiquetas — Etiquetas tipo PII, PCI, tenant, jurisdicción. El FGAC y las listas blancas de recuperación las consumen; no son adorno.
Enmascaramiento — Transformar una columna (hash, últimos cuatro, nulo) para que un principal consulte la tabla sin recibir valores sensibles en claro.
Observabilidad de agentes — Trazas de prompts, llamadas a herramientas, alcances de datos, latencia, coste y resultados. Véase /es/glossary/agent-observability/. La observabilidad dice qué ocurrió; sola no dice si estaba permitido.
Deriva de agente — Desviación de comportamiento o de alcance de datos respecto a evaluaciones y política de línea base: fuentes, herramientas o permisos nuevos sin un release controlado.
Aplicación de política en runtime — Denegar, enmascarar o acotar antes de que la acción termine. Contrasta con modelos solo-log o de recertificación por lotes.
RAG frente a acceso por herramienta — Recuperación sobre un corpus frente a consultas/API en vivo. Perfiles de riesgo distintos: chunks viejos o demasiado amplios frente a SQL con exceso de privilegio. Ambos necesitan perímetro; ninguno sustituye al otro.
Lista blanca de recuperación — El conjunto nombrado de documentos o tablas que un agente puede embeber o consultar. El FGAC más rápido para datos no estructurados.
MCP (Model Context Protocol) — Costura estándar de herramientas y contexto. Gobernadlo como cualquier API: identidad, alcance, registro, límites de tasa. Véase /es/glossary/mcp/.
Evaluaciones (evals) — Pruebas estructuradas con criterio de aprobado/suspenso sobre el comportamiento del agente. Véase /es/glossary/evaluation-evals/. Necesarias para la puerta de publicación y para comparar deriva.
HITL (humano en el bucle) — Aprobación humana en pasos con consecuencia. Véase /es/glossary/human-in-the-loop/.
Concesiones JIT — Elevación acotada en el tiempo para un propósito declarado; evita escritura permanente en cuentas de servicio de agentes.
DSPM (gestión de la postura de seguridad de datos) — Descubrimiento y clasificación de datos sensibles en almacenes — incluidos conjuntos en la sombra que el agente puede encontrar primero.
Sincronización de política — La misma regla lógica aplicada en varios motores (p. ej. masking Snowflake + filtro de fila Unity Catalog + filtro Lake Formation) sin duplicar a mano por plataforma.
Proliferación de cuentas de servicio — Credenciales compartidas, con exceso de privilegio o sin seguimiento que heredan los agentes; causa silenciosa número uno de incidentes de «datos incorrectos».
Identidad de agente — El principal no humano que ve el motor (cuenta de servicio, identidad de carga, usuario delegado). Si se toma prestada de un humano o se comparte entre agentes, ya habéis perdido la auditoría.
IA en la sombra (shadow AI) — Copilotos, plugins o claves API personales fuera de inventario y perímetro.
Inyección de prompt / abuso de herramientas — Instrucciones controladas por un atacante o por un documento que cambian el comportamiento del agente, incluida la llamada a herramientas que el usuario no pretendía. Terreno de la ola A; sigue haciendo falta la ola B si la herramienta puede devolver las filas incorrectas.
Guardarraíles — Restricciones de entrada, herramienta y salida. Véase /es/glossary/guardrails/. Necesarios; no sustituyen al FGAC.
Quién debería hacer qué
Aún no hay agentes en producción. No compréis una plataforma. Mapead un flujo, atad una identidad de mínimo privilegio a los filtros de fila humanos que ya existan, contratad una herramienta de lectura, añadid dos evaluaciones «no debe ver», dejad el envío humano. Leed la Línea de Pobreza de Gobernanza si la presión de presupuesto tienta a saltarse el inventario.
Piloto atascado en «revisión de TI». Os falta evidencia de perímetro, no capacidad de modelo. Un diagrama de una página: identidades, herramientas, puntos de aplicación, una traza de ejemplo, resultados de evaluación incluyendo una fila denegada.
Retirasteis un agente en vivo. Tratad la retirada como temario. Recortad a un flujo; añadid FGAC en ruta en el almacén que el agente realmente tocó; reconstruid evaluaciones con los casos de fallo; volved a pilotar con las puertas humanas intactas.
Escaláis más allá de un flujo. Estandarizad gateway o capa de confianza, catálogo compartido, cuadros de deriva y patrones JIT. Ahí sí puede coincidir un RFP de plataforma enterprise con la realidad — no antes.
Predicciones (nuestra lectura)
- Las startups de seguridad de agentes adquirirán o se aliarán a fondo con FGAC de datos — el TAM solo de prompts es demasiado estrecho para retiradas impulsadas por exposición de PII.
- MCP forzará la consolidación de gateways — demasiados servidores de herramientas sin auditar para que un CISO los acepte; enriquecer logs de gateway con identidad de agente y propósito se volverá el default.
- Los compradores pedirán «enseñad el perímetro» antes que «enseñad la nota de evaluación» — porque las retiradas tipo Sinch son primero incidentes de datos.
- Las funciones nativas de gobernanza de IA en catálogo (AI Gateway de Databricks, políticas Snowflake, filtros Lake Formation) absorberán cuota mid-market por debajo de la Línea de Pobreza de Gobernanza antes que las plataformas standalone.
- La monitorización de deriva se vuelve artefacto de cumplimiento — el Reglamento de IA de la UE y las normas sectoriales esperan cada vez más evidencia continua de comportamiento, no un PDF único de red team.
Cierre en voz baja
Construimos los encargos de Capa Operativa de IA con la misma disciplina de perímetro: alcance estrecho, herramientas con contrato, aplicación en la costura de datos, evaluaciones, trazas, puertas humanas. Eso cruza nuestras prácticas de gobernanza de IA y gobernanza de datos — un sistema gobernado, no un chatbot más una hoja de políticas.
Si queréis una lectura directa de dónde cruza vuestro primer agente el Perímetro de Producción — y qué aplicar antes de escalar — empezad por un presupuesto Web & eCommerce o US → EMEA.
Fuentes
- Sinch AI Production Paradox — nota de prensa y capítulo de retos de producción
- Trust3 AI — visión de plataforma
- Privacera — About FGAC (secundario; referencia de patrón)
- Databricks — Unity Catalog
- Snowflake — seguridad a nivel de columna
- AWS — filtros de datos de Lake Formation
- Apache Ranger — https://ranger.apache.org/
- Lakera — plataforma de seguridad de IA
- Preamble — evaluaciones de seguridad de agentes
- Guardrails AI — https://guardrailsai.com/
- NVIDIA — NeMo Guardrails
- LangChain — State of Agent Engineering 2026
- OpenAI — guía práctica de agentes (PDF)
- Yerbabuena — Por qué fracasan los proyectos de IA agéntica, Datos listos para IA, Línea de Pobreza de Gobernanza
Preguntas frecuentes
¿Qué es el Perímetro de Producción?
Nuestro término para la frontera aplicada donde las herramientas del agente — servidores MCP, conectores SQL, APIs — encuentran datos gobernados. La política, el enmascaramiento y los filtros de fila deben ejecutarse en ruta antes de que una consulta o una recuperación devuelva filas. Registrar no es un perímetro.
¿Por qué las empresas de gobernanza de datos tienen ventaja con la IA agéntica?
Los agentes amplifican las rutas de acceso existentes a velocidad de máquina. Quien ya aplica política de fila y columna, la sincroniza entre motores y puede reconstruir linaje ya tiene la mitad difícil de la producción. Un cortafuegos de prompts no filtra filas en un SQL ni dice qué chunks fundamentaron una respuesta.
¿Qué es la deriva de un agente?
Desviación de comportamiento o de alcance de datos respecto a las evaluaciones de línea base en producción: tablas nuevas, mezcla de herramientas que cambia, permisos que crecen en una cuenta de servicio. Se detecta comparando trazas en vivo con el juego de evaluaciones y el inventario de políticas con los que se publicó, no solo con la versión del modelo.
¿Cómo llevamos agentes a producción más rápido sin exponer datos incorrectos?
Primero se reduce la superficie de datos, después el agente. Un flujo, una identidad, herramientas con contrato, FGAC en ruta sobre las tablas que ese flujo necesita, evaluaciones desde el día uno y un humano en las acciones irreversibles. Un programa de catálogo completo no es prerrequisito; una lista blanca de recuperación y un principal de mínimo privilegio para ese flujo sí.