El día que nuestra IA privada le mostró a un empleado un salario que no debía ver

El memorándum que no funciona

En algún lugar de su empresa, en este mismo momento, alguien ha pegado el contrato de un cliente en un chatbot para resumirlo. No lo consultó. No es alguien malintencionado. Tenía una fecha límite y una herramienta que funcionaba, y esa herramienta resultó enviar ese contrato a un servidor propiedad de una empresa en otro continente.

Lo sé porque todos los CISO con los que he trabajado tienen el mismo panel, y este cuenta la misma historia. Uno de ellos abrió Netskope en una reunión y me mostró 317 aplicaciones de IA generativa distintas en uso activo en toda su organización. Él había autorizado un puñado de ellas. El resto eran sus empleados resolviendo sus propios problemas, un pegado a la vez.

Esa brecha —entre la IA que usted ha aprobado y la IA que su gente realmente está usando— es el problema que he dedicado la última etapa de mi carrera a resolver, construyendo Veriprajna. Nos dedicamos al despliegue de LLM privados: ponemos un modelo de lenguaje grande capaz dentro de su propia infraestructura, bajo sus propios controles, para que el trabajo que sus empleados ya están haciendo con IA deje de filtrarse por el costado del edificio. La IA soberana no es un discurso filosófico sobre la independencia tecnológica nacional. Es la respuesta práctica a una pregunta que todo líder de seguridad ya está fallando en responder: ¿adónde van nuestros datos y podemos demostrarlo?

El instinto, cuando uno ve por primera vez ese panel, es enviar un memorándum. Prohibir las herramientas. Probé esa idea al principio, y quiero contarle exactamente por qué se desmorona, porque ese fracaso es toda la razón por la que existe esta empresa.

Prohibir la IA no la elimina de su empresa. Solo elimina su visibilidad sobre ella.

Las cifras lo demuestran mejor que yo. El informe Cost of a Data Breach 2025 de IBM concluyó que una de cada cinco organizaciones ya ha sufrido una filtración vinculada a la IA en la sombra —herramientas no autorizadas usadas sin el conocimiento de TI—. Esas filtraciones costaron en promedio $670,000 más que los incidentes tradicionales, y tardaron 247 días en detectarse frente a 241 para todo lo demás. Una encuesta aparte lo dijo sin rodeos: el 43 % de los empleados admite compartir información laboral confidencial con herramientas de IA que su empleador nunca aprobó. Una prohibición no cambia ese comportamiento. Solo garantiza que usted será el último en enterarse cuando salga mal.

¿Por qué un chatbot privado no soluciona la IA en la sombra?

Así que, si no puede prohibirla, construye la alternativa segura. Levanta un chatbot interno, lo conecta a un buen modelo y le dice a todos que usen ese en su lugar. Aquí es donde cometí mi error más costoso, y vale la pena detenerse en él porque casi todo el mundo lo comete.

El primer despliegue interno con el que estuve cerca lucía genial en la demostración. Interfaz limpia, respuestas rápidas, un modelo que conocía los documentos de la empresa. Estábamos orgullosos de él. Luego, durante el piloto, alguien en un puesto júnior le hizo una pregunta sobre un plan de compensación, y respondió. Por completo. Con precisión. Con detalles extraídos de un documento que esa persona no tenía por qué leer.

Nada había sido hackeado. El sistema de recuperación hizo exactamente lo que lo construimos para hacer: encontrar los documentos más relevantes y entregárselos al modelo. Simplemente nunca le habíamos enseñado que relevancia y permiso son cosas diferentes. El chatbot era un bibliotecario fiel al que se le había dado la llave maestra de todas las salas cerradas del edificio.

Esa tarde replanteó todo el problema para mí. El modelo nunca fue la parte difícil. La parte difícil es el permiso.

Esto es lo que nadie le dice en las demostraciones de los proveedores: la mayoría de las empresas arrastran años de lógica de acceso acumulada enterrada en Active Directory: grupos de seguridad anidados, permisos heredados, listas de distribución, unidades organizativas superpuestas unas sobre otras por personas que se marcharon hace años. Cuando construye un sistema de recuperación, la jugada ingenua es etiquetar cada fragmento de texto con una lista plana de quién puede verlo. Eso se derrumba en el momento en que se topa con el anidamiento real de grupos. Un documento hereda el acceso de un grupo, que hereda de otro grupo, al que se añadió a un contratista para un único proyecto hace años.

Hacer esto bien es el verdadero trabajo. Construimos una capa de sincronización que se sitúa entre el proveedor de identidad —Active Directory, Okta, Azure AD— y la base de datos vectorial donde viven los documentos. Resuelve la pertenencia a grupos de forma recursiva, aplana esas cadenas de herencia y actualiza los metadatos de acceso con una cadencia ajustada. Para la mayoría de los despliegues sincronizamos cada 60 a 90 segundos. Pero el caso que le quita el sueño es la terminación: alguien es escoltado a la salida a las 9 a. m., y no puede permitir que el sistema siga respondiendo con su acceso a las 9:05. Así que las revocaciones no esperan a la siguiente sincronización: un webhook de Okta o Azure AD dispara una purga inmediata en el instante en que la cuenta se deshabilita.

La relevancia y el permiso no son lo mismo, y un sistema de recuperación que los confunde entregará la respuesta correcta exactamente a la persona equivocada. Ninguna plataforma de RAG importante resuelve esto de fábrica; lo comprobé buscando.

Eso no es confianza de marketing: es lo que encontré al buscar. TrueFoundry, Databricks, los productos de búsqueda nativos de la nube: todos tienen respuestas parciales: verificaciones de permisos de solo lectura, sincronizaciones periódicas. Ninguno hereda el panorama completo de las políticas de grupo y las reglas basadas en atributos —acceso por tiempo limitado, «solo desde un dispositivo gestionado», niveles de clasificación— sobre las que realmente funciona una empresa regulada. Por eso construimos ese motor de políticas como trabajo a medida, porque no hay atajo para ello. Si quiere la arquitectura completa de cómo funciona esta aplicación de permisos de extremo a extremo, está expuesta en nuestra página de IA soberana y despliegue de LLM privados.

¿Un centro de datos en Fráncfort hace que su IA sea europea?

Hay una segunda trampa, y es más sutil porque parece cumplimiento normativo. Muchas empresas recurren a una opción gestionada —Azure OpenAI, AWS Bedrock— y se sienten seguras. Los datos permanecen en su propio inquilino de la nube. Hay puntos de conexión VPC, redes privadas, un conjunto de certificaciones. Para muchas empresas, esa es genuinamente la respuesta correcta, y se lo diré a la cara a un cliente cuando lo sea.

Pero hay un hecho legal por debajo del técnico que veo que la gente pasa por alto constantemente. Alojar su IA en un centro de datos de Fráncfort no la hace europea. Microsoft y Amazon son empresas con sede en Estados Unidos, y eso las somete a la CLOUD Act estadounidense, que permite a las fuerzas del orden estadounidenses obligar a una empresa de EE. UU. a entregar datos que almacena en cualquier parte del mundo. El artículo 48 del RGPD dice que una orden de un tribunal extranjero solo es válida aquí con un acuerdo internacional. Esas dos leyes apuntan en direcciones opuestas, y sus datos quedan en el hueco entre ambas.

Esto dejó de ser teórico en marzo de 2026. La Autoridad de Protección de Datos de Austria multó a una fintech vienesa con EUR 450,000 por realizar la calificación crediticia a través de una API de IA con sede en EE. UU., dictaminando que era una transferencia de datos ilícita bajo el RGPD. La empresa había asumido, como casi todo el mundo hace, que el alojamiento en la región europea era suficiente. No lo era. Mantengo ese dictamen marcado como favorito porque es la ilustración más clara que he encontrado de un riesgo que la mayoría de los consejos de administración no saben que están asumiendo.

El caso especular es una cadena hospitalaria estadounidense: allí la CLOUD Act apenas cuenta, pero los requisitos de asociado comercial de la HIPAA y —en el momento en que toca contratos federales— el Marco de Gestión de Riesgos de IA del NIST y FedRAMP High se convierten en la línea que traza en su lugar. La cuestión de la jurisdicción conserva la misma forma; solo cambia la ley escrita en la pared.

Para una firma financiera estadounidense sin clientes europeos, nada de esto importa y Azure OpenAI suele ser exactamente lo correcto. Para un banco europeo que procesa los datos de sus propios clientes, el cálculo se invierte, y la única configuración que elimina por completo la exposición a la CLOUD Act es un despliegue autoalojado sobre modelos de pesos abiertos que se ejecutan en una infraestructura cuyo operador no está sujeto a la jurisdicción estadounidense. Esa es la función real de los proveedores europeos de nube soberana: OVHcloud, Scaleway, la nueva capacidad Blackwell que está entrando en funcionamiento en Europa. No patriotismo. Jurisdicción.

Y el plazo es real. Las obligaciones de transparencia del artículo 50 de la Ley de IA de la UE se vuelven exigibles el 2 de agosto de 2026. Sume las sanciones de la Ley de IA a las del RGPD y el tope combinado alcanza los 55 millones de euros, o el 11 % de la facturación anual global. Esa no es una multa que se absorbe. Es una cifra que acaba con carreras.

«Solo usa la API»: la conversación que tengo cada mes

La objeción que oigo con más frecuencia es financiera, y es justa: el autoalojamiento suena caro. ¿Por qué comprar GPU y contratar a un equipo cuando una API está a un cargo de tarjeta de crédito de distancia?

Porque las cuentas cambian, y el punto en el que cambian es más específico de lo que la gente espera. Para un modelo autoalojado de 70 000 millones de parámetros, la inferencia cuesta alrededor de $0.013 por cada mil tokens. El mismo trabajo a través de una API alojada como GPT-4o mini cuesta $0.15 a $0.60 por cada mil. Eso no es una diferencia de redondeo. Pero solo importa por encima de cierto volumen, porque las GPU autoalojadas cuestan dinero tanto si las usa como si están inactivas.

El punto de equilibrio se sitúa en torno a los dos millones de tokens al día. Por debajo de esa línea, ganan las API: no está pagando por hardware inactivo, y le diré a un cliente que se quede en las API sin pestañear. Por encima de ella, el autoalojamiento ahorra entre un 60 y un 85 % en inferencia. Una fintech que conozco redujo su factura mensual de IA de $47,000 a $8,000 al pasar a un autoalojamiento híbrido.

Pero —y esta es la parte que ocultan las etiquetas de precio de las GPU— el hardware rara vez es la partida más grande. A los precios de hoy, una H100 se alquila por entre $2.50 y $3.50 la hora, y una sola ejecutando un modelo de pesos abiertos como Llama 3.3 70B atiende de 30 a 50 usuarios simultáneos con una latencia inferior a dos segundos. La parte cara es la gente. Necesita ingenieros de MLOps —dos como mínimo para una fiabilidad de producción— a un coste de $200,000 a $350,000 cada uno, más monitorización, canalizaciones de evaluación y una estrategia de reversión. Para un equipo nuevo en la ejecución de modelos, el coste total de propiedad se sitúa en torno a 3,2 veces el coste bruto de la API en el primer año. Para un equipo maduro con herramientas ya existentes, baja a alrededor de 1,8 veces.

¿Esa fintech que redujo su factura de forma tan drástica? Funcionó porque ya tenían un equipo de Kubernetes y 18 meses de cicatrices operativas. El mismo movimiento habría llevado a la quiebra a un equipo que aprendiera sobre la marcha.

La GPU es la parte más barata del autoalojamiento. Los dos ingenieros que lo mantienen en funcionamiento son la partida que decide si las cuentas realmente cuadran, y cualquiera que responda «¿deberíamos autoalojar?» más rápido que «depende de su volumen y de su equipo» le está vendiendo algo.

La buena noticia bajo todo esto es que los modelos de pesos abiertos se volvieron lo suficientemente buenos como para que valga la pena plantearse la pregunta siquiera. Llama 3.3 70B alcanza el 86 % en el benchmark MMLU y se ejecuta unas 25 veces más barato autoalojado que la API equivalente. DeepSeek-V3 obtiene un 88,5 %, superando por poco a un modelo propietario de frontera en esa medida. Para la gran mayoría de las tareas empresariales, el modelo que puede ejecutar dentro de sus propios muros ya no es la solución de compromiso que era hace dos años.

Qué ocurre cuando la IA deja de solo hablar

Un avance convierte todo esto de prudente en urgente. La IA de su empresa está a punto de dejar de ser un chatbot y empezar a ser un agente: software que no solo responde preguntas, sino que ejecuta acciones, con acceso permanente a sus sistemas.

Gartner prevé que el 40 % de las aplicaciones empresariales incorporen agentes de IA para finales de 2026, frente a menos del 5 % un año antes. Pero solo alrededor del 5 % de las empresas ha llevado realmente los agentes del piloto a producción, y el panorama de seguridad es genuinamente alarmante: el 92 % de los líderes de seguridad dice que carece de visibilidad completa sobre las identidades de IA que ya operan en su entorno. Un agente que puede leer su CRM, presentar tickets y mover dinero es un riesgo muy distinto al de un chatbot que puede resumir un PDF.

Todo lo que he descrito —la aplicación de permisos, el control de la jurisdicción, los guardrails en tiempo de ejecución que atrapan la inyección de prompts— deja de ser un simple valor añadido en el momento en que su IA puede actuar. Un chatbot que recupera el documento equivocado es una vergüenza. Un agente con acceso permanente y sin límite de permisos es un incidente esperando una fecha.

Este es el replanteamiento con el que le dejaría. La capa de guardrails también importa aquí, y vale la pena saber que las opciones listas para usar, como NeMo Guardrails de NVIDIA, añaden una latencia real, de 100 a 300 milisegundos por llamada, razón por la cual ajustamos la lógica de políticas al patrón de cumplimiento específico en lugar de acoplar un filtro genérico. Pero el punto más profundo es arquitectónico. No se puede poner un agente sobre una infraestructura que no se controla y llamarlo gobernado.

La parte que la gente siempre rebate

La gente me pregunta si realmente tienen que elegir, si pueden conservar algunas API en la nube y aun así llamarse soberanos. Sí: la mayoría de los despliegues que recomendaría son híbridos, con las cargas de trabajo sensibles en infraestructura privada y las de bajo riesgo en API gestionadas, con un límite de política claro que decide cuál es cuál. La soberanía nunca fue un voto de todo o nada; se trata de trazar la línea en el lugar correcto y poder demostrar dónde se encuentra.

La otra pregunta es el momento: ¿no es demasiado pronto? La multa austriaca ya cayó. El plazo del artículo 50 está en el calendario. Sus empleados están pegando datos en cientos de herramientas que usted no ha aprobado mientras lee esto. El coste de moverse pronto es un proyecto. El coste de moverse tarde se mide frente a un tope del once por ciento de la facturación.

Fundé Veriprajna porque vi cómo un fiel y pequeño chatbot le entregaba a un empleado júnior un salario que jamás debería haberle mostrado, y me di cuenta de que toda la industria vendía modelos cuando el verdadero problema era el control. El modelo es la parte fácil. Siempre lo fue.

Su gente no está esperando permiso para usar la IA. La única pregunta abierta es si la IA que están usando le responde a usted.

Si quiere ver cómo diseñamos ese control para un perfil de riesgo específico —dónde debería situarse la línea entre lo privado y lo gestionado, cómo se construye la capa de permisos, cuál es el coste total real para su equipo—, eso es lo que exponemos, con honestidad y sin favorecer a ningún proveedor, en la página de IA soberana de Veriprajna. Traiga su panel. Ya sé más o menos lo que dice.