Certificación de IA para empresas
Tu empresa ya depende de la IA. ¿Puedes demostrar que es segura?
Las herramientas y los agentes de IA leen tus datos, hablan con tus clientes y actúan con tus permisos. Cuando fallan, ante el cliente suele responder tu empresa.1 Certificar es pasar de «confiamos en el proveedor» a «lo hemos probado y puede comprobarlo un tercero independiente».
Hablar con nuestro agente Cómo se certifica
Texto, investigación y revisión de Michael Gradek. Actualizado el 17 de octubre de 2026, con el estado de las fuentes a esa fecha. Vesta Seguros es una correduría independiente, inscrita en el registro de la DGSFP con la clave J4583. No es asesoramiento jurídico.
Por qué certificar: la IA ya no solo responde, actúa
Una empresa que depende de herramientas y agentes de IA asume un riesgo que nadie ha medido por ella: el del proveedor del modelo, el de su propia configuración y el de todo lo que la IA lee por el camino. Certificar es medirlo con pruebas y que lo confirme un tercero, antes de que lo mida un incidente, un cliente o un regulador.
Actúa con tus permisos
Un agente no se limita a redactar: lee correos y bases de datos, llama a otras herramientas y ejecuta acciones. Su error ya no es un texto equivocado, sino un pedido, un borrado, una promesa o una fuga. Un agente de programación borró la base de datos de producción de un usuario durante una congelación de código,2 y un tribunal canadiense hizo responder a una aerolínea por lo que dijo su chatbot, que ella consideraba una entidad separada.1
Nadie lo ha comprobado por ti
Ni la demostración del proveedor ni las pruebas públicas de los modelos examinan tu configuración, tus datos y tus permisos. Y las pruebas independientes dicen que todo puede fallar: en una competición pública hubo al menos un ataque exitoso contra los 13 modelos de frontera que se probaron,3 el NCSC británico advierte de que la inyección de órdenes quizá nunca se resuelva del todo4 y, en las evaluaciones de AIUC, las peticiones corrientes produjeron más hallazgos (22,0 %) que los ataques (2,9 %), aunque son datos propios y sin auditar.5
Conclusión práctica: parte de que puede fallar y demuestra cuánto daño puede hacer.
La ley, además, ya ha fijado las fechas que importan:
- 2 ago 2026. Transparencia (art. 50 del Reglamento de IA): los sistemas que interactúan con personas deben avisar de que son una IA.8
- 2 dic 2026. Marcado legible por máquina del contenido sintético de los sistemas ya comercializados.9
- 9 dic 2026. Responsabilidad por productos: el software, también la IA, cuenta como producto.10
- 2 dic 2027. Obligaciones de alto riesgo del anexo III.9
- 2 ago 2028. Obligaciones de alto riesgo del anexo I.9
Seis puertas por las que una IA puede hacerte daño
Los fallos de seguridad de una IA no son de un solo tipo. Se agrupan en seis puertas: dos por las que entra información (los datos y las órdenes), dos por las que sale (lo que dice y lo que hace) y dos que dependen del tiempo (los cambios y el rastro). Es nuestra forma de ordenar los riesgos que recogen la lista de OWASP11 y los seis dominios de AIUC-1.5
Datos: lo que lee y lo que puede filtrar
Qué puede salir mal. Datos sensibles que se pegan en herramientas, información a la que el agente accede sin que quien pregunta pudiera verla y contenido que sale por canales que nadie vigila. Según el informe de IBM de 2026, el 92 % de las organizaciones que sufrieron ataques a sus modelos de IA no controlaba bien el acceso, y la IA no autorizada intervino en el 43 % de los incidentes, más del doble que un año antes.12
Cómo se comprueba. Se mapea qué datos toca cada herramienta o agente, se siembran registros de prueba para ver si salen por alguna vía y se revisa que el agente solo vea lo que puede ver quien le pregunta.
Referencias: OWASP LLM02:2025, divulgación de información sensible · AIUC-1: Data & privacy.
Órdenes ajenas: quién puede mandarle sin que lo sepas
Qué puede salir mal. Un modelo de lenguaje no distingue bien entre datos e instrucciones: lo que lee (un correo, una web, un documento, la descripción de una herramienta) puede reescribir su tarea. El NCSC británico advierte de que esta inyección de órdenes quizá nunca se resuelva del todo,4 y la combinación peligrosa es la de tres capacidades: acceso a datos privados, exposición a contenido no fiable y comunicación hacia fuera.13 Un fallo así en un asistente de ofimática recibió 9,3 sobre 10 de gravedad, sin que el usuario hiciera nada.14
Cómo se comprueba. Con pruebas adversarias (red teaming): intentos directos e indirectos, en varios turnos y a través de las herramientas, repetidos muchas veces; y una revisión de diseño que busca la combinación de las tres capacidades y la rompe con controles que no dependan de que el modelo acierte.
Referencias: OWASP LLM01:2025, inyección de órdenes · AIUC-1: Security.
Respuestas: lo que puede inventar, prometer o decir mal
Qué puede salir mal. Respuestas falsas dichas con aplomo, compromisos que no existen, contenido fuera de lugar o sesgado. En España, el TSJ de Galicia multó con 1.800 € a un abogado por usar IA sin verificar las citas de un recurso;15 en Canadá, un tribunal dijo que da igual que la información venga de una página fija o de un chatbot.1 Y acertar a veces no basta: un agente que acierta el 80 % de las veces acierta ocho seguidas solo en torno al 17 % de los casos (cálculo propio),16 por eso la fiabilidad se mide con pruebas repetidas.17
Cómo se comprueba. Con escenarios escritos con tus casos reales y respuestas correctas definidas de antemano, repetidos muchas veces y graduados por gravedad; además se prueban los casos fuera de alcance y los contenidos que no debe producir.
Referencias: OWASP LLM09:2025, desinformación · AIUC-1: Reliability, Safety y Society.
Permisos: lo que puede romper
Qué puede salir mal. Credenciales demasiado amplias, acciones irreversibles sin una puerta humana y copias de seguridad al alcance del mismo agente. Cuanto más puede hacer un agente, más pesa cada error: en 2025, un agente de programación borró la base de datos de producción de un usuario durante una congelación de código, y la empresa reconoció que nunca debería haber sido posible.2
Cómo se comprueba. Se revisa qué puede leer, escribir y enviar el agente y hasta dónde llegaría si lo controlara otro; se intentan acciones destructivas fuera de su alcance y se comprueba que exigen aprobación humana y que existe un interruptor para pararlo.
Referencias: OWASP LLM06:2025, exceso de agencia · AIUC-1: Security.
Cambios: lo que se mueve bajo tus pies
Qué puede salir mal. El proveedor actualiza el modelo, alguien cambia las instrucciones, se añade una herramienta o una fuente de datos: lo que se probó ya no es lo que funciona. Un certificado describe una configuración en una fecha: la auditoría de AIUC-1 es puntual, sin periodo de observación,18 y exige repetir las pruebas al menos cada tres meses.19
Cómo se comprueba. Se fijan las versiones del modelo y de las instrucciones, se define qué cambios obligan a repetir pruebas y se vigila el comportamiento en producción. Nuestra lectura: en la documentación pública de AIUC las repeticiones se fijan por calendario, no por cambio; pídelo por contrato.
Referencias: AIUC-1: Reliability.
Rastro: lo que puedes demostrar y parar
Qué puede salir mal. Si no queda registro de qué hizo el agente, quién lo autorizó y cómo se detiene, no se puede investigar un incidente, responder a un cliente ni enseñar nada a un auditor o a una aseguradora.
Cómo se comprueba. Se verifica que existen el registro de acciones, un responsable con nombre, un procedimiento de parada y una revisión de incidentes, y que funcionan: con una prueba de parada, no solo con un documento.
Referencias: AIUC-1: Accountability.
Cómo se certifica una IA, a vista de pájaro
Certificar una IA es someterla a tres preguntas con pruebas repetibles y que un tercero independiente verifique la evidencia. No hay una sola certificación: según lo que quieras probar se combinan varias, y ninguna sustituye a la vigilancia diaria.
- ¿Hace lo que debe? Uso corriente: escenarios de tu negocio, repetidos muchas veces.
- ¿Resiste que lo empujen? Ataque: manipulación, fuga de datos y abuso de herramientas.
- ¿Qué pasa si cae? Alcance: qué puede leer, tocar y enviar si alguien lo controla.
- Delimitar. Qué agente o herramienta se evalúa, qué lee, qué escribe y qué envía, quién lo usa y qué queda fuera; lo que no se prueba se declara.20
- Revisar los controles. Políticas, configuraciones y registros frente a una norma: la ISO/IEC 42001 para el sistema de gestión de la organización y AIUC-1 para un agente concreto.21 19 El marco de gestión de riesgos del NIST y la lista de riesgos de OWASP son guías voluntarias de referencia, no esquemas de certificación.22 11
- Probar. Miles de escenarios sobre una instancia igual que la de producción, con datos realistas: AIUC habla de entre 1.000 y 5.000 por agente.20 Cada respuesta se gradúa por gravedad y se repite lo que falla.23
- Auditar. Un auditor independiente revisa la evidencia de cada requisito. En AIUC-1 solo AIUC emite el certificado, y pide que no quede abierto ningún hallazgo crítico ni mayor.19 23
- Repetir. Pruebas periódicas (en AIUC-1, al menos cada tres meses, con un certificado de 12 meses)19 y, nuestra lectura, también cuando cambie el modelo, las instrucciones o los permisos.
Qué significa «cero fallos». Si en 1.000 pruebas independientes no aparece ningún fallo, solo puede afirmarse que la tasa real es, como mucho, de un 0,3 % (con un 95 % de confianza); con 5.000 pruebas, un 0,06 %.16 Y solo si las pruebas son independientes y se parecen al uso real: las variantes de un mismo escenario no suman muestra independiente.
| Esquema | Qué mira | Quién lo verifica |
|---|---|---|
| ISO/IEC 42001 | El sistema de gestión de IA de una organización, dentro del alcance que ella define21 | Un organismo de certificación acreditado21 |
| AIUC-1 | Un agente concreto: controles y pruebas técnicas20 | AIUC ejecuta las pruebas y emite el certificado; un auditor acreditado por AIUC revisa la evidencia19 23 18 |
| NIST AI RMF y OWASP LLM Top 10 | Un marco de gestión de riesgos y una lista de riesgos de las aplicaciones con modelos de lenguaje22 11 | Nadie: son referencias de uso voluntario |
Lo que un certificado no es
Un certificado es una señal útil, no una garantía. Describe una configuración concreta en una fecha concreta, y su valor depende de quién lo da y de cómo se probó.
- No es una garantía. AIUC lo dice de su propio certificado: es una evaluación puntual de controles, no una garantía de comportamiento futuro.19 La auditoría no tiene periodo de observación.18
- No es cumplimiento legal. AIUC presenta su correspondencia con el Reglamento de IA solo con fines informativos y aclara que no es asesoramiento jurídico;24 no hemos encontrado ninguna fuente que muestre que un regulador o un tribunal trate AIUC-1 o la ISO/IEC 42001 como cumplimiento.
- No es neutral por definición. En AIUC-1, la misma entidad redacta el estándar, ejecuta las pruebas, emite el certificado, acredita a los auditores y vende el seguro; un analista de SANS lo compara con el modelo de las agencias de calificación en el que paga el emisor, y sus fundadores responden que asegurar agentes certificados pone en juego su propio dinero.25 Pregunta siempre quién escribe las reglas, quién hace las pruebas y quién cobra.
- No prueba que pierdas menos. El 16 de septiembre de 2026, el cofundador de AIUC confirmó que aún no había habido ninguna reclamación;26 no hay datos de que los agentes certificados fallen menos. Por eso el valor está en el proceso (delimitar, probar, corregir, repetir) más que en el sello.
Preguntas frecuentes
¿Qué es certificar una IA o un agente de IA?
Es que un tercero independiente compruebe, con pruebas repetibles y revisión de evidencias, que una herramienta o un agente concreto cumple unos criterios de seguridad y fiabilidad, y lo deje por escrito. No es un sello genérico: describe una configuración concreta en una fecha concreta.19
¿Es obligatorio certificar las herramientas de IA de mi empresa?
No hay una obligación general. El Reglamento de IA exige una evaluación de conformidad a los proveedores de sistemas de alto riesgo antes de comercializarlos, y esas obligaciones se aplazaron al 2 de diciembre de 2027 (anexo III) y al 2 de agosto de 2028 (anexo I).8 9 Para el resto de usos, certificar es voluntario: una decisión de riesgo y de confianza ante clientes y aseguradoras.
¿Un certificado garantiza que la IA no fallará?
No. Describe una configuración en una fecha, y AIUC advierte de que no es una garantía de comportamiento futuro.19 Incluso un modelo bien probado puede ser manipulado: en una competición pública, todos los modelos probados fallaron al menos una vez.3 El certificado ayuda a limitar y a demostrar el riesgo; no lo elimina.
¿Un certificado de IA equivale a cumplir el Reglamento de IA?
No. AIUC presenta su correspondencia con el Reglamento como información, sin valor de asesoramiento jurídico, y no hemos encontrado ninguna fuente que muestre que un regulador o un tribunal trate AIUC-1 o la ISO/IEC 42001 como cumplimiento. Cumplir exige analizar tu caso con asesoramiento jurídico.24
¿Qué incluye vuestra consultoría de certificación y qué no?
Incluye ayudarte a inventariar tu IA, elegir el esquema de certificación, preparar controles, evidencias y el plan de pruebas, y coordinarte con los certificadores y auditores acreditados, que son quienes hacen las pruebas técnicas y la auditoría; como correduría, también leemos qué cubren tus pólizas. No incluye emitir certificados, garantizar su resultado ni sustituir al asesoramiento jurídico.
¿Por dónde empiezo si usamos muchas herramientas de IA?
Por un inventario: qué herramientas y agentes se usan, quién los usa, qué datos tocan y con qué permisos. Sin él no se sabe qué certificar primero, y puede haber IA que nadie ha autorizado: la IA no autorizada intervino en el 43 % de los incidentes que estudió IBM en 2026.12 Después se priorizan los agentes que hablan con clientes, actúan con credenciales o tocan datos sensibles.
Sigue leyendo
- EU AI Act: guía práctica 2026: el calendario del Reglamento de IA.
- Formación en IA (AI Act): la formación del artículo 4 para quienes usan IA en tu equipo.
- Ciberseguro para grandes empresas y ciberseguro para pymes: lo que cubre una póliza de ciber y cómo se negocia.
Siguiente paso
Certificación de IA a medida para tu empresa
Cada empresa usa la IA de forma distinta: otras herramientas, otros datos, otros permisos. Por eso no vendemos un paquete: diseñamos contigo la certificación que encaja con lo que usas y con lo que te piden.
- Inventario y mapa de puertas. Qué IA usas, también la que nadie ha autorizado, qué datos toca y con qué permisos.
- Plan de certificación. Qué esquema encaja con cada herramienta o agente, en qué orden y con qué auditores acreditados.
- Preparación. Controles, evidencias, plan de pruebas y las correcciones que pidan los hallazgos.
- Lectura de tus pólizas. Como correduría, qué cubre cada póliza de lo que descubramos.
Vesta no emite certificados: los emite un tercero independiente. No garantizamos el resultado de una certificación ni de una renovación de seguro.
Fuentes (26)
- The Guardian, sobre el caso de Air Canada y su chatbot (16 de febrero de 2024). www.theguardian.com ↩
- Fortune, sobre el agente de Replit que borró una base de datos de producción (23 de julio de 2025). fortune.com ↩
- CAISI (NIST), blog sobre la competición pública de ataques a agentes de IA (23 de marzo de 2026). www.nist.gov ↩
- NCSC (Reino Unido), entrada de blog sobre la inyección de órdenes frente a la inyección SQL (8 de diciembre de 2025). www.ncsc.gov.uk ↩
- AIUC, portal de auditores de AIUC-1: introducción, seis dominios y muestra de 85.000 evaluaciones (consultado el 14 de octubre de 2026). standard.aiuc-1.com ↩
- Insurance Business, sobre la exclusión de IA generativa de Verisk ISO en pólizas de RC general de EE. UU. (16 de septiembre de 2026). www.insurancebusinessmag.com ↩
- Insurance Business, análisis de un endoso de IA para ciber de una aseguradora del mercado de Londres (17 de septiembre de 2026). www.insurancebusinessmag.com ↩
- Reglamento (UE) 2024/1689, texto consolidado a 27 de julio de 2026, artículos 16, 43, 50 y 113. publications.europa.eu ↩
- Reglamento (UE) 2026/1744 (Ómnibus digital sobre IA), artículo 1, puntos 39 y 40 (24 de julio de 2026). publications.europa.eu ↩
- Directiva (UE) 2024/2853 sobre responsabilidad por los daños causados por productos defectuosos, artículos 2, 4 y 22. publications.europa.eu ↩
- OWASP Gen AI Security Project, lista de los diez principales riesgos de las aplicaciones con modelos de lenguaje, edición de 2025 (consultada el 17 de octubre de 2026). genai.owasp.org ↩
- Cybersecurity Dive, sobre el informe de IBM y el Ponemon Institute de 2026 sobre el coste de las brechas de datos (29 de julio de 2026). www.cybersecuritydive.com ↩
- Simon Willison, «The lethal trifecta for AI agents» (16 de junio de 2025). simonwillison.net ↩
- Registro CVE-2025-32711, publicado por Microsoft (11 de junio de 2025). www.cve.org ↩
- Poder Judicial (CGPJ), «El TSXG multa a un abogado con 1.800 euros por el uso sin verificar de IA en un recurso» (15 de julio de 2026). www.poderjudicial.es ↩
- Cálculo propio: con cero fallos en n pruebas independientes, la cota superior aproximada de la tasa de fallos, al 95 % de confianza, es 3/n («regla de los tres»); y 0,8 elevado a 8 es 0,17. ↩
- Yao, Shinn, Razavi y Narasimhan, «τ-bench», sobre la fiabilidad de los agentes en pruebas repetidas (17 de junio de 2024). arxiv.org ↩
- AIUC, portal de auditores de AIUC-1: trabajo de campo de la auditoría (consultado el 17 de octubre de 2026). standard.aiuc-1.com ↩
- AIUC, preguntas frecuentes del estándar AIUC-1 (consultadas el 17 de octubre de 2026). standard.aiuc-1.com ↩
- AIUC, portal de auditores de AIUC-1: alcance del agente y de las evaluaciones (consultado el 17 de octubre de 2026). standard.aiuc-1.com ↩
- CASRAI, guía sobre la ISO/IEC 42006 y quién puede certificar la ISO/IEC 42001 (actualizada el 25 de septiembre de 2026). casrai.org ↩
- NIST, página del marco de gestión de riesgos de IA (AI RMF), de uso voluntario (consultada el 17 de octubre de 2026). www.nist.gov ↩
- AIUC, portal de auditores de AIUC-1: evaluaciones técnicas (consultado el 17 de octubre de 2026). standard.aiuc-1.com ↩
- AIUC, correspondencia de AIUC-1 con el Reglamento de IA de la UE (consultada el 14 de octubre de 2026). standard.aiuc-1.com ↩
- Lenny Zeltser (SANS Institute), análisis de AIUC-1 (22 de abril de 2026). zeltser.com ↩
- Latent Space, entrevista a Rune Kvist, cofundador de AIUC (16 de septiembre de 2026). www.latent.space ↩