Escrito para quien dice que no.
Todo proyecto de IA empresarial termina frente a un arquitecto de seguridad cuyo trabajo es encontrar la razón por la que esto no puede salir. Esa revisión es donde mueren la mayoría de los pilotos — no porque las objeciones sean irrazonables, sino porque nadie diseñó para ellas. Esta página es el conjunto de respuestas, expresadas con claridad suficiente para pegarlas en un cuestionario.
Las siete preguntas, respondidas en una línea
01
¿A dónde van nuestros datos?
A ningún lado. Se queda en su VPC.
02
¿Dónde corre el código generado?
MicroVMs aisladas por hardware.
03
¿Y si es comprometido?
Salida denegada por defecto.
04
¿Quién puede hacer qué?
Su IdP, intersectado por turno.
05
¿Y los datos personales?
Tokenizados antes de transmitir.
06
¿Puede actuar por su cuenta?
En una escritura, nunca.
07
¿Qué ve un auditor?
La cadena causal completa.
08
¿Podemos correr sin internet?
Sí. El mismo código.
01 · Frontera de confianza
El proveedor nunca retiene sus datos.
La mayoría de los proveedores de IA le pide aceptar que sus datos propietarios se procesen en infraestructura que usted no controla, bajo un acuerdo de tratamiento y una promesa. Para una Fortune 500 con cláusula de residencia de datos, eso no es una negociación — es un rechazo.
Por eso la arquitectura se parte en una línea dura. La orquestación decide qué sigue y no retiene datos del cliente. La ejecución vive por completo en su cuenta de nube y es lo único que toca alguno de sus sistemas.
Plano de control · nuestro
- ·Ciclo de sesión, enrutamiento y compilación del agente
- ·Evaluación de políticas y puerta de pre-ejecución
- ·Recolección de trazas y medición
- ✕Ningún dato del cliente en reposo
↕ mTLS + W3C TraceContext
Plano de ejecución · suyo
- ·Corre en su VPC, en su cuenta, bajo su IAM
- ·El único componente que conecta a sus sistemas
- ·Ejecución de código en sandbox con política de salida forzada
- ✓Sus datos nunca cruzan la frontera
02 · Aislamiento de ejecución
Asuma que el agente es hostil. Diseñe en consecuencia.
Un agente que escribe y ejecuta código es, arquitectónicamente, una vía de ejecución remota que usted construyó a propósito. El aislamiento a nivel de contenedor no basta — un contenedor comparte kernel, y los escapes de kernel son una categoría conocida, no una hipótesis.
Sandbox a nivel de hipervisor
El código generado corre en una MicroVM — un hipervisor a nivel de hardware — con su propio kernel. La frontera de aislamiento es el hipervisor, no un namespace. Un escape exitoso deja al atacante en una máquina virtual vacía.
Salida denegada por defecto
Cada sandbox lleva un filtro de red eBPF y un sumidero DNS. El tráfico saliente se restringe a una lista que usted define, así un agente totalmente comprometido no tiene a dónde enviar nada. La exfiltración requiere un destino, y no hay ninguno.
Salida escaneada al salir
Un sidecar inspecciona todo lo que emite el sandbox antes de salir, detectando datos personales que una consulta devolvió de forma incidental. Defensa en profundidad: el tokenizador actúa a la entrada, el escáner a la salida.
Lista eBPF y sumidero DNS activos. Dos destinos aprobados; tres rechazados.
Filtro desactivado: el mismo agente, la misma ejecución, sin la política de salida.
04 · Identidad y autorización
Los permisos se intersectan, no se heredan.
El modo de falla en la mayoría de las plataformas agénticas es una sola cuenta de servicio con acceso amplio, lo que significa que cada usuario tiene efectivamente la unión de los permisos de todos. Aquí el catálogo de herramientas disponible en un turno es la intersección triple de lo que la plataforma soporta, lo que su inquilino tiene habilitado y lo que permite el rol de ese usuario.
available_tools = platform ∩ tenant ∩ rbac
→ compiled into a signed session manifest, per turn
- → Ingreso SAML 2.0 y OIDC contra Azure AD, Okta, Google, ADFS o un proveedor propio
- → Tokens en almacenamiento respaldado por gestión de claves, nunca en configuración
- → El historial de sesión revalida la autorización al acceder, así un rol revocado pierde también sesiones pasadas
- → Las especificaciones en caché llevan un hash de permisos y expiran al cambiar los derechos
05 · Privacidad
Los datos sensibles nunca llegan al modelo.
La tokenización contextual reemplaza los fragmentos sensibles antes de transmitir y reinyecta los valores reales tras la respuesta, de modo que el usuario ve una respuesta completa mientras el modelo solo vio marcadores. Es clave que esto lo gobierne una política declarativa y no reglas codificadas — su equipo de cumplimiento puede leerla y modificarla.
Lista de categorías
Qué clases de datos se tokenizan — nombres, identificadores nacionales, instrumentos financieros, datos de salud.
Patrones empresariales propios
Sus propios formatos de identificador — números de cuenta internos, códigos de parte, referencias de caso — tratados como sensibles aunque ningún escáner genérico los reconocería.
Lista de exclusión segura
Exclusiones literales y por patrón para valores que parecen sensibles pero no lo son, para que la sobre-tokenización no degrade la calidad.
Reglas de contexto omitido
Exclusiones por etiqueta y por precedencia, más anulaciones por dominio, para que la política difiera entre una transcripción de soporte y un libro contable.
06 · Control humano
Las lecturas son libres. Las escrituras se detienen. Siempre.
"Humano en el ciclo" suele ser una diapositiva, no un mecanismo. Aquí es una máquina de estados con tres propiedades que resisten condiciones adversas.
PROPERTY 01
El impacto se muestra, no se describe
La puerta muestra un diff de exactamente qué cambiaría y cuántos registros alcanza. Un revisor que aprueba "actualizar las oportunidades" sin ver cuáles doce no está revisando, está haciendo ceremonia.
PROPERTY 02
Las aprobaciones no se pueden repetir
Cada aprobación se ancla a un token de concurrencia optimista y al esquema con el que se otorgó. Si el plan o la definición de la herramienta cambian tras la aprobación, el token ya no coincide y la escritura se rechaza en lugar de ejecutarse contra algo que nadie revisó.
PROPERTY 03
Escalar es un resultado de primera clase
Aprobar y rechazar no bastan. Un revisor que no es la persona indicada puede escalar, lo que enruta la decisión sin aprobarla por inercia ni descartar el trabajo en silencio.
La misma puerta aplica en cada solución. En ingeniería de pruebas es la cola de revisión antes de escribir un caso en su herramienta ALM. En flujos agénticos es la puerta antes de actualizar un registro. En inteligencia de negocios es el diff antes de sobrescribir una versión del tablero. Un mecanismo, tres superficies — por eso una revisión de seguridad de uno se traslada a los demás.
07 · Auditabilidad
Reconstruir la decisión, no un resumen de ella.
Seis meses después alguien preguntará por qué el sistema cambió un registro, y "lo decidió la IA" no es una respuesta que sobreviva a una auditoría. Cada acción del agente se traza de extremo a extremo con contexto distribuido propagado entre los planos de control y ejecución, así la cadena causal es reconstruible y no inferida.
- →Qué turno disparó qué llamada, con los argumentos recibidos
- →Qué devolvió esa llamada y qué cita de la narrativa apunta a ella
- →Quién aprobó la escritura resultante, cuándo y contra qué token de versión
- →Qué rechazó la puerta y por qué la política se evaluó así
trace_id 4bf92f3577b34da6a3ce929d0e0e4736
├─ ingress user=j.rivera@ · role=analyst
│ ├─ tokenize 14 spans held
│ └─ injection scan clean
├─ route NEW_TASK · 84ms
├─ factory manifest signed · 9 tools
│ └─ intersection platform∩tenant∩rbac
├─ tool warehouse.aggregate
│ └─ returned 84,112 rows → pointer [1]
├─ gate crm.update HELD
│ ├─ blast_radius 12 records
│ ├─ version_token v7 · pinned
│ └─ approved m.okafor@ · 14:22:07Z
├─ tool crm.update COMMITTED
└─ egress detokenize · render
08 · Despliegue
Cuatro topologías. Un solo código.
Elegir la opción restrictiva no debería dejarlo en una rama rezagada. Es el mismo código en cada topología, por eso el despliegue on-premises no es una degradación.
Kubernetes / Helm
Más común
On-premises o BYOC dentro de su clúster existente, bajo su política de red y su malla de servicios.
Docker
Inicio rápido
Despliegue con Compose y base de datos gestionada, apropiado para un piloto acotado en infraestructura aislada.
Binario firmado
Sin red
Un ejecutable de escritorio firmado criptográficamente para entornos donde no se permite ejecutar un servicio.
Nube gestionada
Menor operación
Operamos el plano de control; el de ejecución sigue en su cuenta. Adecuado cuando la residencia de datos no es la restricción vinculante.
Sobre la inferencia y el acceso al modelo
No exigimos un proveedor de modelo específico ni introducimos una nueva ruta saliente. La inferencia se enruta por el gateway que su organización ya aprobó — un gateway de IA interno, un endpoint nativo de nube en su propia suscripción, o un modelo auto-alojado. Los embeddings de recuperación corren residentes y localmente en lugar de llamar a un servicio alojado, y eso es lo que hace viable, y no teórico, un despliegue con salida totalmente restringida.
Pruebas adversarias
Ataques contra los que diseñamos, por nombre.
Un proveedor que no puede nombrar los ataques contra su propia clase de sistema no los ha buscado. Cada uno de estos tiene una mitigación específica en el código, y cada uno se ejercita en la fase de endurecimiento del proyecto.
| Ataque | Mitigación |
|---|---|
| Suplantación de herramienta | Un servidor malicioso registra una herramienta que suplanta a una confiable. Las colisiones de nombre fallan cerradas — la solicitud se deniega en lugar de resolverse por conjetura. |
| Inyección en descripción | Instrucciones ocultas en el texto de descripción de una herramienta. Las descripciones se tratan como entrada no confiable y no pueden redirigir al agente. |
| Evasión por subconsulta | Una operación restringida anidada en una subconsulta para burlar una regla de coincidencia textual. Las consultas se analizan en árbol sintáctico y se validan estructuralmente. |
| Salida por URL / SSRF | Una cita o puntero renderizado como enlace a un destino controlado por el atacante. Las URLs se validan contra una lista permitida antes de renderizar. |
| Repetición de aprobación | Reutilizar una aprobación otorgada contra un plan modificado. Las aprobaciones se anclan a un token de concurrencia y al esquema aprobado; una discrepancia rechaza la escritura. |
| Falsificación de citas | El modelo emite marcadores de apariencia autorizada que inventó. Las citas las genera el backend desde el registro de llamadas; los marcadores sin correspondencia se eliminan. |
| Reintento con duplicado | Una falla transitoria en una escritura no idempotente que se vuelve transacción duplicada al reintentar. Las guardas de reintento son conscientes de idempotencia por operación. |
FAQ
Directo del cuestionario.
El plano de control orquesta y no retiene datos del cliente; el plano de ejecución corre en su VPC y es lo único que toca sus sistemas. Se comunican por TLS mutuo con contexto de traza distribuida propagado en la unión, de modo que el rastro de auditoría sobrevive a la frontera. En un despliegue on-premises ambos planos corren en su entorno y la frontera se vuelve interna.
No tiene a dónde enviar nada ni nada que pueda escribir unilateralmente. El código se ejecuta en una MicroVM con su propio kernel, así que la frontera es el hipervisor y no un namespace. La salida está denegada por defecto vía filtrado eBPF y sumidero DNS. Toda escritura sigue requiriendo aprobación humana anclada a un token de versión. El peor caso realista son lecturas no autorizadas dentro del catálogo que el rol de ese usuario ya permitía — por eso importa la intersección triple de permisos.
Sí. La inferencia se enruta por el gateway que ya aprobó — incluido un modelo auto-alojado — y los embeddings corren residentes y localmente en lugar de llamar a un servicio alojado. El despliegue soporta Kubernetes y Helm en su propia infraestructura, o un binario único firmado donde no se permite ejecutar un servicio. Es el mismo código, así que la topología restrictiva no es un conjunto reducido de funciones.
Las credenciales de conexión y claves de API se cifran en reposo con cifrado simétrico autenticado antes de llegar a cualquier base de datos, y nunca se escriben en configuración en texto plano. Los tokens de identidad se guardan en almacenamiento respaldado por gestión de claves bajo su propio material criptográfico. En un despliegue BYOC u on-premises el almacén está dentro de su perímetro, así que no retenemos nada — no tenemos acceso al entorno donde viven esos secretos.
Dos semanas de su atención al inicio, no una firma al final. Las semanas uno y dos definen topología de despliegue, residencia de datos, proveedor de identidad, política de salida y requisitos de auditoría, y producen un modelo de amenazas y un diagrama que sus revisores ya vieron. Posponer esa conversación al final es la razón más común por la que los proyectos de IA empresarial incumplen su fecha.
Envíe el cuestionario antes de la demostración.
Preferimos responder cuarenta preguntas de seguridad por escrito y luego mostrarle algo, que mostrarle algo y pasar dos meses respondiéndolas. Envíenos la evaluación que usa su equipo de riesgo de proveedores.
Escrito sobre esto
La ingeniería detrás, en detalle
Comparativa
Bedrock Agents y Vertex AI Agent Builder: Lo Que Decide por Usted un Entorno Gestionado
Cuatro decisiones arquitectónicas que hereda con un entorno gestionado, el único compromiso escrito que lo descarta, y por qué el costo de cambio no está donde se le busca.
Desglose
Desglose: La Arquitectura de Ejecución en Dos Planos
Un plano de control que no retiene datos del cliente, un plano de ejecución dentro de su VPC y una frontera de hipervisor entre el código generado por el agente y todo lo demás. Contra qué defiende cada capa, y lo que cuesta esa forma.
Seguridad
Por Qué los Pilotos de IA Empresarial Mueren en la Revisión de Seguridad
El piloto funcionó. Dieciocho meses después sigue sin estar en producción. Cinco preguntas de arquitectura deciden ese resultado, y las cinco se resuelven antes de la primera línea de código.
Seguridad
La Inyección de Prompts Es un Problema de Contención, No de Prompts
La defensa y el ataque comparten canal, así que ninguna instrucción cierra la clase. Cuatro ataques nombrados y las capas arquitectónicas que vuelven inofensivo uno exitoso.
Arquitectura
BYOC, SaaS u On-Premises: Cómo Elegir la Topología de Despliegue para IA Empresarial
La topología de despliegue no es un detalle de infraestructura que se resuelve después. Determina qué datos puede tocar el sistema, y es la decisión más difícil de revertir.