Estimados amigos de Inseguros !!!
Tu empresa ya utiliza IA. ¿Pero quién tiene realmente el control?
Hay algo que me está llamando muchísimo la atención en las empresas durante los últimos meses.
La velocidad a la que están incorporando inteligencia artificial.
Un departamento empieza utilizando ChatGPT para preparar informes.
El equipo comercial utiliza Claude para analizar documentación.
Recursos Humanos empieza a probar herramientas para clasificar currículums.
Los técnicos utilizan agentes capaces de ejecutar comandos, consultar repositorios y automatizar tareas.
Y alguien descubre que puede conectar Copilot con SharePoint, Teams y otras aplicaciones.
Todo estupendo.
La productividad aumenta, los trabajadores encuentran nuevas posibilidades y dirección está encantada con todo lo que promete la inteligencia artificial.
Pero entonces aparece una pregunta que no siempre sabemos responder.
¿Quién está controlando todo esto?
Y no me refiero a quién paga las suscripciones de ChatGPT.
Me refiero a algo bastante más importante.
¿Sabemos qué aplicaciones de IA están utilizando nuestros trabajadores?
¿Qué información están enviando?
¿Con qué cuentas se conectan?
¿Qué permisos tienen los agentes?
¿Quién autoriza una nueva integración?
¿Quién puede acceder a los registros?
¿Y quién responde si uno de estos sistemas realiza una acción que nunca debería haber realizado?
Porque estamos pasando de utilizar herramientas de inteligencia artificial a incorporar sistemas que tienen capacidad para acceder a información y actuar sobre nuestros procesos empresariales.
Y eso requiere algo más que una política que diga que los empleados no deben compartir datos confidenciales.
Necesitamos gobierno.
Pero también necesitamos controles técnicos.
Y, sobre todo, tenemos que comprobar que esos controles funcionan.
Hoy quiero hablaros de algo que considero fundamental para los próximos años: el Gobierno y la Seguridad de la Inteligencia Artificial en las empresas.
Vamos a ello.
1. Tu empresa puede tener más inteligencia artificial de la que imaginas
Empecemos por una situación bastante habitual.
Le preguntamos al responsable de informática qué soluciones de inteligencia artificial utiliza la empresa.
Y nos responde:
Tenemos Microsoft Copilot para algunos usuarios.
Perfecto.
Pero después empezamos a investigar.
Y descubrimos que algunos empleados utilizan ChatGPT con sus cuentas personales.
Otros utilizan Claude para analizar documentos.
El equipo de desarrollo trabaja con asistentes de programación.
Marketing ha contratado varias herramientas de generación de contenido.
Y diferentes departamentos utilizan servicios SaaS que incorporan funcionalidades de inteligencia artificial.
¿Cuántas de estas herramientas estaban en el inventario de IT?
Probablemente no todas.
Aquí aparece un concepto que ya conocemos de otros ámbitos de la seguridad: Shadow IT.
Y ahora también hablamos de Shadow AI.
Es decir, inteligencia artificial utilizada dentro de la organización sin que exista necesariamente un proceso de autorización, supervisión y control.
Y quiero dejar algo claro.
No creo que la solución sea prohibir ChatGPT, Claude y todas las herramientas de IA.
Eso puede provocar que los trabajadores busquen maneras alternativas de utilizarlas.
La solución tiene que pasar por conocer qué están utilizando, comprender para qué lo necesitan y proporcionar alternativas y controles adecuados.
Porque quizás el empleado que está utilizando ChatGPT por su cuenta está resolviendo un problema que la empresa todavía no ha sabido atender.
Y eso también debemos escucharlo.
Pero una cosa es permitir la innovación y otra dejar que cada departamento decida individualmente qué herramientas pueden tratar la información empresarial.
Primera obligación: saber qué IA tenemos, quién la utiliza y para qué.
Sin inventario no podemos gobernar prácticamente nada.
2. Gobierno de IA: no quiero un comité para organizar más reuniones
Vamos a hablar del gobierno.
Y aquí tengo que hacer una advertencia.
Porque cuando escucho palabras como gobernanza, políticas, comités y procedimientos, me preocupa que terminemos convirtiendo un problema técnico y empresarial en una fábrica de documentos.
Y no quiero eso.
El gobierno de la IA debería ayudarnos a responder preguntas muy concretas.
¿Qué queremos conseguir utilizando IA?
¿Qué sistemas están autorizados?
¿Quién puede aprobar un nuevo caso de uso?
¿Qué riesgos debemos evaluar?
¿Qué datos pueden utilizarse?
¿Quién es responsable de cada sistema?
¿Qué controles necesita antes de entrar en producción?
¿Y cómo vamos a comprobar que sigue funcionando correctamente?
Eso sí tiene sentido.
Podemos establecer un comité o una oficina de gobierno de IA, interna o externa, donde participen diferentes áreas.
IT, porque necesita comprender la arquitectura y las integraciones.
Seguridad, porque debe evaluar los riesgos y definir los controles.
Procesos y negocio, porque son quienes conocen los objetivos y las necesidades de cada caso de uso.
Legal y cumplimiento, porque determinadas aplicaciones requieren evaluar obligaciones normativas y de protección de datos.
Pero quiero insistir en algo.
No necesitamos que un comité se reúna durante tres horas para autorizar que un trabajador utilice una herramienta de productividad de bajo riesgo.
Necesitamos un modelo proporcionado.
Los casos sencillos deberían disponer de procedimientos sencillos.
Los sistemas que afectan a datos sensibles, decisiones importantes o procesos críticos deberían requerir controles más exigentes.
El gobierno de IA no debería dificultar la innovación. Debería permitirla sin perder el control.
Y eso exige combinar organización y tecnología.
3. No es lo mismo un chatbot que un agente con permisos sobre tus sistemas
Aquí viene uno de los cambios más importantes.
Durante los primeros años de popularización de la IA generativa, muchos sistemas estaban orientados principalmente a generar contenido.
Escribíamos una pregunta.
Recibíamos una respuesta.
Y decidíamos qué hacer con ella.
Pero ahora tenemos agentes.
Y los agentes pueden incorporar herramientas capaces de consultar información, conectarse con APIs y ejecutar acciones.
Imaginemos un agente que gestiona determinadas tareas administrativas.
Puede consultar documentación.
Revisar facturas.
Acceder a una aplicación empresarial.
Y actualizar información.
Hasta aquí, estupendo.
Pero ahora necesitamos hacernos algunas preguntas.
¿Con qué identidad trabaja?
¿Con los permisos del usuario?
¿Con una identidad de aplicación?
¿Con una cuenta de servicio?
¿Puede consultar únicamente los recursos necesarios?
¿Tiene permisos de lectura?
¿Puede modificar información?
¿Puede eliminar datos?
¿Quién autoriza sus operaciones?
Porque hay una diferencia enorme entre un sistema que responde preguntas sobre las vacaciones de los empleados y otro que puede modificar registros en una base de datos empresarial.
Ambos utilizan inteligencia artificial.
Pero los riesgos no tienen nada que ver.
Y, sin embargo, en ocasiones tratamos ambos proyectos como si fueran simplemente dos aplicaciones nuevas.
No podemos gobernar todos los agentes con una política genérica.
Necesitamos evaluar sus capacidades.
Sus identidades.
Sus permisos.
Las herramientas que utilizan.
Y las consecuencias de sus acciones.
Precisamente por eso, en SeguridadSi ofrecemos servicios de Gobierno y Seguridad de IA para empresas, donde trabajamos tanto la organización y las políticas como los controles técnicos necesarios para supervisar estos sistemas.
Porque un agente no deja de ser un nuevo componente de nuestra arquitectura empresarial.
Y debemos tratarlo con la misma seriedad que a cualquier otra aplicación crítica.
4. La identidad del agente: una de las grandes preguntas que debemos resolver
Quienes me conocéis sabéis que llevo muchísimos años trabajando con Active Directory, Microsoft Entra ID y seguridad de identidades.
Y precisamente por eso hay algo que me preocupa especialmente de los agentes de inteligencia artificial.
La identidad.
En un sistema empresarial tradicional solemos tener bastante claro quién está realizando una operación.
Un usuario se autentica.
Obtiene determinados permisos.
Accede a una aplicación.
Y la aplicación verifica si puede realizar lo que solicita.
Pero cuando incorporamos agentes aparecen nuevos escenarios.
Un usuario puede iniciar una tarea.
El agente puede consultar información.
Después invocar una herramienta.
Y esa herramienta puede conectarse a otro sistema utilizando credenciales diferentes.
Ahora quiero que pensemos en algo.
¿Sabemos qué identidad se está utilizando realmente en cada paso?
Porque no es lo mismo que una operación se ejecute con permisos delegados del usuario que mediante una identidad de aplicación con acceso global.
Y tampoco es lo mismo que una herramienta utilice un token limitado que unas credenciales administrativas.
Aquí debemos prestar especial atención al mínimo privilegio.
Un agente que solamente necesita consultar información no debería tener permisos para modificarla.
Y una aplicación que trabaja con datos de un departamento no debería disponer innecesariamente de acceso a toda la organización.
Además, debemos gestionar correctamente secretos, certificados y tokens.
Controlar sus ámbitos de autorización.
Establecer mecanismos de revocación.
Y comprobar quién puede modificar los permisos.
Todo esto nos debería sonar.
Son principios que llevamos años aplicando en seguridad.
El problema es que ahora tenemos nuevos componentes a los que también debemos aplicarlos.
Y no podemos delegar esas decisiones exclusivamente en el modelo de lenguaje.
5. MCP y herramientas: necesitamos controlar qué puede ejecutar realmente la IA
Vamos ahora con uno de los temas que más me interesan técnicamente.
MCP.
Model Context Protocol permite integrar aplicaciones y agentes con herramientas y fuentes de información.
Un agente puede utilizar herramientas para consultar documentos, acceder a determinados servicios o ejecutar operaciones.
Y todo esto facilita muchísimo la creación de automatizaciones.
Pero también introduce nuevos riesgos.
Imaginemos que tenemos un agente con acceso a cinco herramientas.
Una permite consultar SharePoint.
Otra consultar una base de datos.
Otra generar informes.
Otra enviar correos.
Y otra modificar registros.
¿Necesita realmente todas esas capacidades?
¿Quién ha autorizado cada herramienta?
¿Con qué identidad se conecta?
¿Se validan los parámetros que recibe?
¿Puede utilizarse para acceder a recursos que no corresponden al usuario?
¿Disponemos de registros de lo que hace?
No deberíamos permitir que un agente utilice una herramienta simplemente porque el modelo considera que necesita hacerlo.
Necesitamos autorizaciones reales.
Y esas autorizaciones deben aplicarse en los sistemas que ejecutan las operaciones.
Podemos utilizar un gateway o una capa de control para centralizar determinadas funciones.
Por ejemplo:
- Identificación y autorización de las solicitudes.
- Control de herramientas permitidas.
- Validación de parámetros.
- Gestión de accesos.
- Integración con una bóveda de secretos.
- Registro de operaciones.
- Aplicación de límites y políticas.
Pero tampoco debemos pensar que desplegar un gateway resuelve automáticamente todos los problemas.
El servidor MCP y las APIs de destino también deben comprobar las autorizaciones.
Y las credenciales deben estar correctamente protegidas.
La seguridad de la IA no consiste en colocar una caja más en el diagrama. Consiste en comprobar que cada componente aplica los controles que le corresponden.
Si quieres profundizar en estos escenarios ofensivos, también tenemos un servicio específico de Pentesting de IA, LLM y agentes.
Porque una cosa es diseñar los controles.
Y otra comprobar qué sucede cuando alguien intenta saltárselos.
6. ChatGPT, Claude y Copilot: ¿qué control tengo sobre las herramientas externas?
Vamos ahora con una cuestión especialmente interesante.
La utilización de plataformas externas de inteligencia artificial.
Muchas empresas están adoptando ChatGPT, Claude, Microsoft Copilot y otras soluciones.
Y tienen buenas razones para hacerlo.
Son herramientas que pueden proporcionar capacidades muy interesantes sin necesidad de desarrollar toda la infraestructura desde cero.
Pero necesitamos entender algo.
No controlamos todas las capas de una aplicación externa de IA.
Y las capacidades disponibles pueden variar mucho según el proveedor, el plan contratado, las funcionalidades activadas y las integraciones autorizadas.
Cuando desarrollamos nuestra propia aplicación podemos diseñar parte de la arquitectura y establecer controles sobre los servicios que gestionamos.
Pero cuando utilizamos una aplicación SaaS, dependemos también de los mecanismos que ofrece su proveedor.
Quizás podamos controlar usuarios.
Permisos.
Conectores.
Políticas de acceso.
Retención de datos.
Registros de determinadas actividades.
Pero eso no significa que tengamos visibilidad completa sobre todo el funcionamiento interno del sistema.
Por eso necesitamos evaluar cuidadosamente qué información entregamos y qué sistemas conectamos.
También debemos revisar las condiciones de tratamiento de datos, las opciones empresariales y las garantías contractuales.
Y, especialmente, controlar los permisos concedidos a las integraciones.
Por ejemplo, una conexión con Microsoft 365 puede requerir autorización para acceder a información empresarial.
Necesitamos saber qué permisos solicita.
Quién los concede.
Qué datos quedan accesibles.
Y cómo revocarlos.
Porque no basta con aprobar el uso de una plataforma de IA. Hay que gobernar sus conexiones con nuestros sistemas.
Y aquí tenemos que trabajar con los controles disponibles en diferentes capas.
Identidad.
Endpoint.
Aplicaciones.
Datos.
Red.
Registros.
Y, cuando corresponda, soluciones EDR y controles de seguridad sobre el entorno donde se ejecuta el agente.
No todas las plataformas permiten introducir los mismos mecanismos de protección.
Precisamente por eso necesitamos evaluar cada arquitectura de forma individual.
7. La protección de datos: ¿qué información estamos entregando a la IA?
Vamos con una de las mayores preocupaciones empresariales.
Los datos.
Una empresa puede utilizar inteligencia artificial para analizar documentación financiera, contratos, información comercial, datos de trabajadores o expedientes de clientes.
Y muchas veces eso resulta perfectamente legítimo.
Pero necesitamos determinar qué información puede utilizar cada sistema.
Y bajo qué condiciones.
Por ejemplo:
¿Estamos utilizando información pública?
¿Documentos internos?
¿Datos confidenciales?
¿Información personal?
¿Secretos empresariales?
¿Tenemos autorización y una base jurídica adecuada cuando tratamos datos personales?
¿Conocemos los proveedores y subencargados implicados?
¿Disponemos de las garantías contractuales necesarias?
¿Sabemos qué políticas de retención se aplican?
No todas las herramientas presentan las mismas garantías.
Y no todas las funcionalidades de un mismo proveedor tienen por qué compartir exactamente las mismas condiciones.
Por eso es importante revisar las características concretas del servicio contratado.
Pero quiero añadir algo más.
La protección de los datos no termina cuando la información llega al modelo.
También debemos controlar lo que sucede cuando un agente recupera información de SharePoint, consulta una base de datos o utiliza una API.
Porque podemos tener una aplicación empresarial con permisos correctamente definidos y después desarrollar un agente que accede utilizando una identidad demasiado privilegiada.
Y entonces podemos crear una vía alternativa para recuperar información que el usuario no debería consultar.
Aquí los controles deben aplicarse también en las fuentes de información.
No podemos confiar en que un prompt de sistema sea suficiente para garantizar la confidencialidad.
Una política que dice «no reveles datos confidenciales» no sustituye un control técnico que impide acceder a ellos.
Y esa diferencia es fundamental.
8. Seguridad en runtime: los controles tienen que funcionar cuando el agente está trabajando
Ahora vamos a una cuestión bastante técnica, pero que considero especialmente importante.
La seguridad en runtime.
Imaginemos que hemos desarrollado un agente y realizado varias pruebas antes de ponerlo en producción.
Todo funciona.
Hemos revisado los prompts.
Hemos establecido algunos guardrails.
Y decidimos desplegarlo.
Perfecto.
Pero durante las siguientes semanas realizamos cambios.
Añadimos una herramienta.
Modificamos el modelo.
Actualizamos una integración.
Conectamos otra fuente de información.
Y ampliamos los permisos de determinadas operaciones.
¿Sigue siendo seguro el agente?
No deberíamos asumirlo.
La seguridad tiene que acompañar el ciclo de vida del sistema.
Y también aplicarse cuando el agente está ejecutando acciones reales.
Por ejemplo, podemos necesitar:
- Comprobar la autorización de cada operación.
- Limitar las herramientas accesibles.
- Validar los parámetros que recibe cada herramienta.
- Impedir determinadas operaciones de alto impacto.
- Solicitar aprobación humana para acciones sensibles.
- Aislar ejecuciones cuando sea necesario.
- Proteger credenciales y secretos.
- Supervisar las actividades del agente.
- Revocar accesos ante comportamientos anómalos.
Y aquí quiero volver a insistir en una idea.
Los guardrails pueden ayudar, pero no sustituyen los controles de seguridad tradicionales.
No podemos dejar toda la responsabilidad en manos de un modelo que interpreta instrucciones probabilísticamente.
Si una operación necesita autorización, esa autorización tiene que comprobarse fuera del modelo.
Y si un usuario no puede acceder a determinada información, tampoco debería conseguirla simplemente porque se lo pida de otra manera a un agente.
El gobierno define qué debe estar permitido.
La arquitectura técnica tiene que imponer esos límites.
Y la monitorización debe ayudarnos a comprobar que se respetan.
9. Los logs de los agentes: ¿podemos reconstruir lo que realmente ha sucedido?
Este apartado me parece imprescindible.
Porque las empresas van a utilizar cada vez más agentes.
Y necesitamos comprender cómo trabajan.
Imaginemos que un usuario solicita una tarea a un agente.
El agente consulta documentación.
Procesa información.
Invoca una herramienta MCP.
Accede a una API empresarial.
Y genera un resultado.
Todo funciona.
Pero después descubrimos que una de las operaciones no estaba autorizada.
¿Podemos reconstruir qué ha sucedido?
Aquí no basta necesariamente con tener un registro que diga que el usuario inició sesión a las diez de la mañana.
Necesitamos un nivel de trazabilidad adecuado al riesgo del sistema.
Idealmente, cuando nuestra arquitectura lo permita, deberíamos poder relacionar información como:
1. Quién inició la operación.
La identidad del usuario, aplicación o proceso.
2. Qué agente intervino.
Su identidad, versión y configuración relevante.
3. Qué modelo y configuración se utilizaron.
Los elementos necesarios para interpretar su comportamiento.
4. Qué herramientas fueron invocadas.
Incluyendo el servidor MCP, la operación y los parámetros relevantes.
5. Qué identidad y permisos se utilizaron.
Para comprender bajo qué contexto se ejecutó la acción.
6. Qué datos estuvieron implicados.
Con controles adecuados para evitar registrar innecesariamente información sensible.
Y, además, necesitamos correlación.
Porque si no podemos relacionar los eventos del usuario, del agente, de las herramientas y de las aplicaciones, resultará mucho más difícil investigar un incidente.
Podemos integrar parte de esta información con una plataforma SIEM como Microsoft Sentinel, siempre que las aplicaciones y servicios proporcionen la telemetría necesaria.
Pero cuidado.
No todos los proveedores permiten obtener los mismos registros.
Y no deberíamos prometer una visibilidad que técnicamente no está disponible.
La solución pasa por diseñar los registros desde el principio, utilizar las capacidades disponibles y reforzar los controles en los sistemas que sí administramos.
Porque si un agente puede actuar sobre nuestros sistemas, necesitamos saber qué ha hecho y disponer de capacidad para responder.
10. AI Act, RGPD y cumplimiento: la IA también tiene obligaciones
Hasta ahora hemos hablado principalmente de tecnología y procesos.
Pero existe otra dimensión fundamental.
La normativa.
En Europa tenemos el Reglamento de Inteligencia Artificial, conocido como AI Act, que establece diferentes obligaciones según el tipo de sistema, el riesgo y el papel que desempeña cada organización.
Y aquí quiero aclarar algo.
No todas las empresas que utilizan ChatGPT tienen exactamente las mismas obligaciones.
No es lo mismo desarrollar y comercializar un sistema de inteligencia artificial que utilizar una solución de un tercero.
Tampoco es lo mismo una aplicación de productividad que un sistema utilizado para determinadas decisiones en ámbitos especialmente sensibles.
Por eso necesitamos analizar cada caso.
A 26 de octubre de 2026, el AI Act se encuentra en aplicación progresiva. Las disposiciones sobre alfabetización en IA y determinadas prácticas prohibidas comenzaron a aplicarse en febrero de 2025; otras obligaciones lo hicieron posteriormente. Tras las modificaciones de 2026, ciertos requisitos para sistemas de alto riesgo cuentan con plazos específicos en 2027 y 2028.
Podéis consultar la información oficial en la Comisión Europea — Reglamento de Inteligencia Artificial.
Pero, independientemente de la clasificación regulatoria, hay cuestiones que considero fundamentales.
Necesitamos conocer nuestros casos de uso.
Evaluar los riesgos.
Determinar responsabilidades.
Documentar decisiones relevantes.
Establecer controles de seguridad y privacidad.
Y disponer de procedimientos de supervisión.
Además, cuando tratamos datos personales, también debemos analizar las obligaciones que correspondan según el RGPD.
Y otras normativas o requisitos sectoriales pueden añadir responsabilidades adicionales.
Aquí es donde deben colaborar los equipos técnicos, legales y de negocio.
Porque no se trata únicamente de cumplir una norma.
Se trata de utilizar inteligencia artificial de forma responsable y controlada.
Y, por favor, no confundamos tener una política de IA con tener implantada su seguridad.
La política es necesaria.
Pero necesitamos demostrar que las medidas funcionan.
11. Las personas: el gobierno de IA no puede quedarse únicamente en IT
Quiero dedicar un apartado a las personas.
Porque todo esto no lo vamos a resolver exclusivamente instalando soluciones técnicas.
Los trabajadores necesitan comprender qué pueden hacer con la inteligencia artificial.
Qué herramientas tienen autorizadas.
Qué datos pueden utilizar.
Qué limitaciones tienen los resultados generados.
Y cómo deben actuar cuando detectan un comportamiento extraño.
Pero también debemos formar a los administradores y desarrolladores.
Porque son quienes tendrán que integrar los agentes con las aplicaciones empresariales.
Gestionar permisos.
Configurar herramientas.
Proteger credenciales.
Y supervisar las operaciones.
Y finalmente necesitamos formar a dirección.
No para convertir a los gerentes en ingenieros de Machine Learning.
Sino para ayudarles a comprender qué posibilidades ofrece la IA, qué riesgos introduce y qué decisiones deben asumir.
La adopción segura de la IA necesita formación técnica, pero también criterio empresarial.
Y esto es importante para evitar dos extremos.
El primero es prohibir cualquier herramienta por miedo.
El segundo es permitir cualquier integración porque promete ahorrar tiempo.
Ambos me parecen errores.
Necesitamos encontrar un equilibrio.
Y para conseguirlo hace falta conocimiento.
12. ¿Cómo implantaría el gobierno de IA en una empresa durante los primeros 90 días?
Vamos con algo práctico.
Imaginemos que una empresa utiliza varias plataformas de inteligencia artificial y quiere empezar a poner orden.
¿Cómo organizaríamos el trabajo?
Yo plantearía una hoja de ruta inicial de tres meses, adaptable al tamaño y madurez de la organización.
Primeros 30 días: conocer lo que tenemos
Lo primero sería realizar un inventario.
Qué aplicaciones de IA se utilizan.
Qué departamentos las utilizan.
Qué agentes existen.
Qué herramientas están conectadas.
Qué datos se procesan.
Quiénes son los responsables.
Y qué permisos se han concedido.
Después clasificaríamos los casos de uso según su criticidad y los riesgos asociados.
También revisaríamos las políticas y procesos existentes.
Porque algunas empresas ya tienen controles que podemos aprovechar.
No necesitamos inventarlo todo desde cero.
Objetivo del primer mes: dejar de trabajar a ciegas.
Días 31 a 60: definir las reglas y los controles
Con el inventario realizado, podemos establecer un modelo de gobierno.
Quién autoriza nuevos proyectos.
Qué evaluaciones deben realizarse.
Qué herramientas pueden utilizarse.
Cómo gestionamos las integraciones.
Qué datos requieren protección adicional.
Qué controles técnicos debemos aplicar.
Y cómo supervisaremos los sistemas más sensibles.
Aquí es donde podemos definir una arquitectura de control para agentes, identidades, herramientas MCP y aplicaciones.
No todas las empresas necesitarán la misma.
Pero todas deberían saber qué están autorizando.
Objetivo del segundo mes: definir quién puede hacer qué y cómo vamos a controlarlo.
Días 61 a 90: implantar, supervisar y validar
Ahora llega la parte importante.
Aplicar las medidas.
Revisar permisos.
Configurar controles.
Establecer registros.
Formar a los equipos.
Y comprobar los casos de uso prioritarios.
En los sistemas más sensibles podemos realizar pruebas técnicas para validar sus límites.
Por ejemplo, mediante un Pentesting de IA y agentes.
También podemos establecer indicadores.
Cuántos casos de uso están inventariados.
Cuántos tienen responsable.
Cuántas integraciones han sido evaluadas.
Cuántos agentes utilizan identidades correctamente gestionadas.
Cuántos sistemas disponen de registros adecuados.
Y cuántos riesgos importantes siguen pendientes.
Objetivo del tercer mes: empezar a demostrar que los controles están funcionando.
No significa que en noventa días hayamos terminado.
Significa que disponemos de un modelo de trabajo y podemos empezar a mejorarlo continuamente.
13. Gobierno de IA y pentesting de IA: dos cosas diferentes que necesitamos conectar
Quiero insistir en algo importante.
Porque en SeguridadSi ofrecemos ambos servicios y no quiero que se confundan.
El Gobierno de IA define cómo debe utilizarse la inteligencia artificial en la organización.
Establece responsabilidades, políticas, procesos, controles y mecanismos de supervisión.
El Pentesting de IA comprueba técnicamente determinados riesgos y qué ocurre cuando alguien intenta abusar de las aplicaciones, agentes, herramientas y permisos.
Pensemos en un ejemplo.
Nuestra política establece que un agente no debe acceder a información confidencial de otro departamento.
Perfecto.
El equipo de desarrollo implanta controles para restringir ese acceso.
También perfecto.
Pero después deberíamos comprobar si realmente es posible eludir esas restricciones.
Y, en caso de que exista algún problema, corregirlo.
Gobernar, implantar, comprobar y mejorar.
Ese es el ciclo.
Y cuando trabajamos con IA conectada a sistemas empresariales necesitamos combinar conocimientos de seguridad tradicional con los nuevos riesgos de modelos, agentes y herramientas.
Porque un agente puede introducir riesgos nuevos, pero sus consecuencias muchas veces terminan afectando a las mismas APIs, identidades y bases de datos que llevamos años protegiendo.
14. SeguridadSi: gobierno y seguridad de IA, pero con controles reales
En SeguridadSi llevamos más de 25 años trabajando en ciberseguridad, tecnologías Microsoft y arquitectura de sistemas empresariales.
Y creo que uno de los mayores retos de los próximos años será conseguir que las empresas adopten inteligencia artificial sin perder el control sobre sus datos, identidades y aplicaciones.
Porque la IA puede aportar muchísimo valor.
No tengo ninguna duda.
Pero necesitamos acompañar esa adopción con criterio.
Por eso ofrecemos nuestro servicio de Gobierno y Seguridad de la Inteligencia Artificial para Empresas.
Un servicio que combina seis áreas fundamentales:
Estrategia y gobierno.
Definimos el modelo organizativo, las responsabilidades, las políticas y los objetivos de adopción.
Seguridad técnica.
Trabajamos sobre identidades, permisos, protección de datos y controles que deben aplicarse durante la ejecución.
Agentes y herramientas.
Revisamos los sistemas agénticos, sus herramientas, integraciones MCP, autorizaciones y gestión de cambios.
Datos y cumplimiento.
Analizamos la información utilizada, los requisitos de privacidad, la normativa aplicable y la trazabilidad.
Personas y procesos.
Ayudamos a que los trabajadores, técnicos y responsables de negocio comprendan cómo utilizar la IA de manera segura.
Monitorización continua.
Definimos los registros, indicadores y mecanismos de supervisión necesarios para detectar problemas y mejorar los controles.
Y todo esto puede integrarse en un programa de consultoría, un Plan Director de Ciberseguridad o un proyecto específico de adopción de inteligencia artificial.
Porque no todas las empresas necesitan lo mismo.
Algunas todavía están intentando comprender qué utilizan sus empleados.
Otras están desplegando Microsoft Copilot.
Otras desarrollan agentes conectados a sus aplicaciones.
Y otras ya tienen sistemas de IA en producción que necesitan evaluar.
Nuestra propuesta es acompañarte desde la decisión hasta la implantación, la supervisión y la mejora.
¿Tu empresa está incorporando inteligencia artificial?
Si estás utilizando ChatGPT, Claude, Copilot, agentes de IA o herramientas conectadas a tus aplicaciones empresariales, quizás sea un buen momento para revisar cómo estás gestionando sus riesgos.
No necesitas detener tus proyectos.
Necesitas comprender qué estás implantando, definir responsabilidades y establecer controles adecuados.
Y podemos ayudarte a hacerlo.
Conoce nuestro servicio de Gobierno y Seguridad de la Inteligencia Artificial para empresas.
Podemos analizar tu situación actual, definir una estrategia, ayudarte a implantar controles técnicos y acompañarte durante la adopción.
Y si ya tienes agentes en funcionamiento, también podemos validar su seguridad mediante nuestro servicio de Pentesting de IA y agentes.
¿Y si quieres aprender cómo funcionan los agentes de IA?
En nuestra academia tenemos formación orientada a profesionales IT que quieren comprender estas tecnologías desde una perspectiva técnica.
Por ejemplo, el Curso de Introducción a la Inteligencia Artificial y agentes con OpenClaw.
Trabajamos conceptos fundamentales de los LLM, modelos locales, agentes como OpenClaw y Hermes, herramientas y mecanismos de seguridad.
Instalamos, configuramos y probamos.
Porque no creo que podamos proteger correctamente una tecnología si no comprendemos cómo funciona.
Y para quienes quieran aprender a estructurar un programa de seguridad empresarial también tenemos el Curso de Controles CIS v8.1, donde trabajamos cómo evaluar, priorizar, implantar y medir controles técnicos.
Ambas formaciones están disponibles dentro de nuestros programas de formación en SeguridadSi.
Y quiero terminar con una reflexión.
La inteligencia artificial no va a esperar a que tu departamento de seguridad termine de escribir sus políticas.
Los trabajadores van a utilizarla.
Los departamentos van a automatizar procesos.
Y las empresas van a conectar agentes con sus aplicaciones.
La pregunta no es si vamos a utilizar inteligencia artificial.
La pregunta es si vamos a gobernarla nosotros o si vamos a descubrir dentro de unos años todo lo que hemos permitido hacer sin control.
Porque innovar está muy bien.
Pero innovar sin saber quién tiene las llaves de tu empresa puede salir bastante caro.
Gracias por leerme.
