A las empresas les venden una historia limpia: “Auditaremos vuestras automatizaciones y os haremos cumplir la normativa”.
A veces quien vende es un abogado que nunca ve cómo funciona realmente el sistema. A veces es un consultor de automatización que hace afirmaciones jurídicas para las que no está cualificado. El entregable final suele ser un documento de políticas, una sesión de formación y una casilla verde en una hoja de cálculo.
Nada de esto demuestra que el sistema desplegado siga respetando la intención humana original que justificó construirlo.
Un buen ejemplo de lo fácil que se abre esa brecha viene de una investigación publicada en julio de 2026. Reuters revisó más de 80 artículos académicos y patentes chinos. Los investigadores habían usado resultados de grandes modelos estadounidenses como material de entrenamiento para sistemas más pequeños y especializados, diseñados para ejecutarse en local, con poca potencia de cálculo, en tareas como analizar código, procesar imágenes u operar cuando fallan las conexiones de red.
Algunas capacidades sí se transfieren. Anthropic señala que, cuando los grandes modelos se destilan en otros más pequeños, algunas de las salvaguardas de seguridad originales pueden debilitarse o perderse.
Pero la investigación no demuestra que comportamientos de seguridad clave, como rechazar peticiones inseguras, expresar incertidumbre o escalar casos delicados, se hayan probado de forma consistente y se haya confirmado que faltan.
Y ese es el verdadero problema: simplemente no sabemos qué se conserva y qué no. Un modelo más pequeño puede seguir pareciendo igual de capaz mientras pierde en silencio las reglas y los límites que daban forma al comportamiento previsto del sistema original.
No es solo una historia militar. El mismo problema de arquitectura puede aparecer cuando una empresa ajusta un modelo, crea un agente interno o entrena un sistema especialista más barato. El comportamiento útil puede trasladarse. El propósito original, las reglas de rechazo y los límites de decisión puede que no se trasladen con él.
Un abogado que revise el contrato del proveedor puede no verlo. Un consultor de automatización que compruebe que el flujo de trabajo “funciona” puede no verlo tampoco. Ambos pueden entregar un paquete de cumplimiento impecable mientras el sistema en funcionamiento se ha alejado de la intención que debía gobernarlo.
El Reglamento Europeo de IA (AI Act) no exige que un abogado dé el visto bueno a cada automatización. No exige 2 personas a jornada completa en cada empresa. Sus obligaciones dependen del papel de la organización y del uso concreto: condición de proveedor o de responsable del despliegue, clasificación del riesgo, transparencia, documentación, supervisión humana, seguimiento y otros requisitos.
Desde el 2 de agosto de 2026, algunas obligaciones de transparencia son aplicables. La Comisión también ha abierto 3 canales de alcance limitado: una herramienta de reclamaciones del AI Act para presuntas infracciones que reúnan los requisitos, una herramienta de denuncia del AI Act para personas con información privilegiada que cumplan las condiciones y que puede usarse de forma anónima, y un canal específico de reclamaciones para proveedores posteriores que informen de posibles fallos de los proveedores de modelos de uso general.
Estas herramientas solo resultan útiles cuando ya existe evidencia. Un documento de políticas no puede reconstruir registros, versiones de modelos, pistas de aprobación ni documentación del proveedor que falta y que el sistema nunca registró.
Estos 3 canales ya están abiertos. Una de las primeras cosas que ahora se pueden denunciar es la falta de transparencia.
Desde el 2 de agosto de 2026 se aplican las obligaciones de transparencia del artículo 50. Hay que informar claramente a los usuarios cuando interactúan con un sistema de IA, por ejemplo un chatbot o una voz de IA en lugar de una persona.
Cierto contenido generado o manipulado con IA debe indicarse de forma visible. Esto incluye los deepfakes y, en condiciones específicas, el texto generado con IA que se publica para informar al público sobre asuntos de interés público cuando no ha habido una revisión humana significativa ni responsabilidad editorial. Los proveedores de sistemas generativos también tienen obligaciones en materia de marcado legible por máquina y de detectabilidad. La indicación concreta depende del tipo de sistema, de contenido y de uso: no todo lo creado con IA requiere la misma etiqueta visible. En el caso del audio, como los pódcast generados con IA, esto suele significar un aviso hablado justo al principio. En los textos escritos, la expectativa práctica es una etiqueta de IA visible colocada encima del texto o cerca del titular.
Los proveedores de sistemas generativos también deben incorporar marcas legibles por máquina para que otros sistemas puedan detectar que el contenido lo produjo una IA.
Los sistemas que ya estaban en el mercado antes del 2 de agosto tienen hasta el 2 de diciembre de 2026 solo para la parte legible por máquina. La obligación de informar a los usuarios de que hablan con una IA y la de etiquetar el contenido generado por IA ya se aplican.
Las multas por incumplir estas normas pueden llegar a 15 millones de euros o al 3 % del volumen de negocio anual mundial. Las pequeñas y medianas empresas no están exentas de la obligación, aunque el importe de la multa puede ajustarse por proporcionalidad.
Muchas empresas que usan IA generativa o chatbots de cara al cliente todavía se están poniendo al día. Un documento de políticas que diga “cumplimos el AI Act” no coloca automáticamente los avisos hablados ni las etiquetas visibles que se exigen en los resultados reales que la gente ve u oye. Esa es otra razón por la que la firma de un abogado o una lista de verificación de automatización no basta. El sistema que está funcionando tiene que producir el comportamiento transparente que la ley exige ahora. Por eso las empresas necesitan 3 cosas, no 2 cargos:
Alguien que pueda mostrar qué hace realmente el sistema: qué modelos, herramientas y datos están conectados, qué acciones puede proponer o ejecutar, qué ocurre cuando se equivoca, qué registros existen y quién es responsable cuando las cosas se desvían.
Alguien que pueda interpretar qué exige la ley para ese uso concreto.
Un responsable dentro de la empresa que responda de ello, que decida el riesgo residual, pueda parar el sistema y defina qué evidencia debe existir antes de ampliar la automatización.
Los asesores externos pueden aportar conclusiones técnicas o asesoramiento jurídico. Pero no pueden asumir la responsabilidad de la organización simplemente firmando un informe.
Aquí el patrón de diseño de Palantir resulta útil porque es operativo. Sus Deployment Strategists y Forward Deployed Engineers (estructura de equipos Echo y Delta) abordan el mismo problema institucional mediante funciones complementarias pero solapadas. El Deployment Strategist (Echo) puede centrarse más en comprender la organización, cuestionar la petición inicial y definir el resultado operativo, mientras que el FDE (Delta) puede centrarse más en convertir esa comprensión en software que funcione. Pero ninguna de las dos funciones empieza solo cuando la otra ha terminado, y ninguna da por hecho que todo problema requiera IA.
Cuando empecé a estudiar con más detalle algunos de sus marcos y su plataforma de despliegue, con Palantir AIP (Artificial Intelligence Platform), vi que los usuarios humanos pueden revisar las acciones propuestas por la IA, inspeccionar las reglas de ejecución y el historial, y aprobar las decisiones críticas mediante puntos de control estructurados. Su guía de gobernanza trata el sistema completo, es decir, los flujos de datos, los permisos, las interfaces, las pistas de auditoría, los flujos de evaluación y prueba y las decisiones humanas, y no solo el modelo.
Su planteamiento de IA soberana añade otra prueba: ¿puede la organización funcionar en la nube, en instalaciones propias, en una nube soberana o en el edge, cambiar de modelo, conservar sus datos y seguir operando sin ceder el control?
Usar a un proveedor estadounidense no hace automáticamente soberana a una empresa europea. La soberanía se demuestra con control, portabilidad, auditabilidad y una capacidad real de salida.
Un botón de aprobación humana sigue sin significar nada cuando quien revisa carece del tiempo, el contexto, la competencia o la autoridad para rechazar la acción.
Antes de aprobar la siguiente automatización, pregúntate:
¿Podemos identificar el modelo, su versión y su origen? ¿Qué acciones requieren aprobación humana y puede esa persona pararlas de verdad? Si alguien reuniera 100.000 resultados, ¿qué parte de nuestra lógica de decisión podría reproducir? ¿Podemos seguir operando y conservar nuestros datos si el proveedor o la red desaparecen? Si mañana llega una reclamación, ¿qué evidencia podríamos presentar?
La IA responsable no empieza cuando un documento de políticas recibe un visto bueno. Empieza cuando lo escrito en la política coincide de verdad con lo que el sistema hace en la práctica, y cuando una persona todavía puede entender, controlar y parar el sistema si empieza a comportarse de una forma no prevista.
Esa es la brecha en la que trabajo.
Fuentes
[1] Reuters, “Chinese military researchers tap US AI models to train defence systems”, 31 de julio de 2026. reuters.com
[2] Comisión Europea, AI Act Service Desk FAQ. ai-act-service-desk.ec.europa.eu
[3] Comisión Europea, AI Act Complaints Tool. digital-strategy.ec.europa.eu
[4] Comisión Europea, AI Act Whistleblower Tool. digital-strategy.ec.europa.eu
[5] Comisión Europea, Complaints channel for downstream providers using GPAI models. digital-strategy.ec.europa.eu
[6] Palantir, documentación de AIP Ethics & Governance. palantir.com
[7] Palantir, Protect Your Sovereignty (planteamiento de IA soberana). palantir.com