Seguridad y privacidad en sistemas de inteligencia artificial
Desarrollamos sistemas de inteligencia artificial para empresas donde la seguridad, la privacidad y el control forman parte de la arquitectura desde el principio.
Definimos qué información puede utilizar cada componente, quién puede acceder a ella, qué acciones puede ejecutar la IA y qué debe ocurrir cuando aparece una excepción.
Porque llevar inteligencia artificial a producción no consiste únicamente en conseguir que un modelo funcione. También consiste en controlar lo que puede ver, lo que puede hacer y lo que ocurre cuando se equivoca.
La seguridad no se añade al final
Un sistema de IA empresarial puede interactuar con:
- documentación interna
- bases de datos
- CRM
- ERP
- correo electrónico
- información de clientes
- aplicaciones internas
- APIs
- sistemas operativos del negocio
Por eso las decisiones de seguridad deben formar parte del diseño.
Antes de desarrollar analizamos:
- qué información necesita realmente el sistema
- qué datos no necesita
- quién puede acceder
- qué sistemas puede consultar
- qué operaciones puede ejecutar
- qué acciones requieren validación
- qué debe registrarse
- qué ocurre ante un error
La arquitectura se diseña alrededor de esos límites.
Privacidad y minimización de datos
Un sistema de IA no debería recibir más información de la necesaria para resolver una tarea.
Aplicamos el principio de minimización para limitar el contexto que se envía a modelos y servicios externos.
Dependiendo del proyecto podemos:
- seleccionar únicamente los campos necesarios
- excluir información sensible
- anonimizar datos o separarlos de la persona
- limitar la retención
- separar diferentes fuentes
- aplicar controles de acceso
- definir políticas distintas según el tipo de información
Esto reduce exposición innecesaria y simplifica el control sobre el sistema.
Los principios de minimización, limitación de finalidad e integridad y confidencialidad forman parte del marco del RGPD y de la protección de datos desde el diseño.
Control de acceso y permisos
No todos los usuarios deberían poder consultar la misma información.
Podemos aplicar permisos según:
- usuario
- rol
- departamento
- organización
- sociedad
- sede
- proyecto
- activo
- tipo de documentación
Por ejemplo, un asistente interno puede estar conectado con miles de documentos y devolver únicamente aquellos que el usuario tiene autorización para consultar.
La IA no debería convertirse en una vía alternativa para saltarse los permisos existentes. Por eso el asistente consulta los sistemas con la identidad y los permisos de la persona que pregunta, no con una cuenta de servicio con acceso global.
Debe respetarlos.
Control sobre las acciones de los agentes de IA
Un agente puede consultar información.
Pero también puede utilizar herramientas y ejecutar acciones.
Por ejemplo:
- crear un registro
- modificar una cita
- actualizar un CRM
- generar una incidencia
- enviar un mensaje
- ejecutar una consulta
- iniciar un flujo de trabajo
No todas esas acciones tienen el mismo riesgo.
Por eso definimos niveles de actuación.
Una operación de bajo impacto puede ejecutarse automáticamente.
Una acción sensible puede requerir:
- comprobaciones adicionales
- reglas de negocio
- límites
- confirmación del usuario
- aprobación humana
La IA interpreta y el código ejecuta.
Y las reglas determinan cuándo una acción está permitida.
No damos libertad ilimitada a un modelo
Un modelo de lenguaje es probabilístico.
Puede interpretar mal una solicitud o generar una respuesta incorrecta.
Por eso evitamos arquitecturas donde el modelo controla directamente procesos críticos sin mecanismos intermedios.
Podemos incorporar:
- herramientas limitadas
- respuestas estructuradas
- validaciones
- listas de operaciones permitidas
- límites de importe o alcance
- estados
- permisos
- confirmaciones
- intervención humana
El objetivo no es conseguir que el modelo nunca se equivoque.
Es diseñar el sistema para que un error del modelo no implique automáticamente un error operativo.
Seguridad en agentes conectados con bases de datos
Un agente no necesita recibir acceso ilimitado a una base de datos.
Diseñamos capas intermedias que controlan:
- qué tablas puede consultar
- qué campos puede utilizar
- qué operaciones están disponibles
- qué filtros deben aplicarse
- qué usuarios pueden acceder
- qué consultas quedan registradas
No dejamos que el modelo escriba y ejecute consultas SQL sobre sistemas de producción.
El modelo interpreta la pregunta y el código construye la consulta, así que no puede salir ninguna consulta fuera de las que ese código sabe construir.
Seguridad en sistemas RAG y documentación interna
Un sistema conectado con documentación empresarial debe controlar tanto qué recupera como quién puede recuperarlo.
Podemos aplicar:
- filtros por usuario
- permisos por documento
- metadata
- separación entre organizaciones
- control de versiones
- fuentes autorizadas
- referencias al documento original
Un sistema RAG no debería asumir que todo documento indexado puede mostrarse a cualquier persona.
La recuperación debe respetar las mismas restricciones que el resto de la organización.
Modelos y proveedores de inteligencia artificial
No todos los proyectos necesitan utilizar el mismo modelo ni el mismo proveedor.
La elección puede depender de:
- privacidad
- ubicación del procesamiento
- tratamiento de los datos
- rendimiento
- coste
- latencia
- capacidad técnica
- requisitos corporativos
También podemos diseñar arquitecturas que reduzcan la dependencia de un único proveedor.
La lógica de negocio se mantiene separada del modelo. Aun así, cambiar de modelo se prueba, no se promete: modelos distintos se comportan distinto y cada cambio pasa la batería de pruebas antes de llegar a producción.
Infraestructura privada y entornos controlados
Determinados proyectos requieren un mayor nivel de aislamiento.
Dependiendo del caso pueden utilizarse:
- entornos cloud controlados
- infraestructura del cliente
- redes privadas
- almacenamiento independiente
- modelos privados
- componentes desplegados dentro de la infraestructura corporativa
En todos los proyectos, la infraestructura se monta en una nube a nombre del cliente y el código es suyo desde el primer día.
No todos los proyectos necesitan este nivel de complejidad.
La arquitectura debe ser proporcional al riesgo, a los datos utilizados y al proceso que queremos automatizar.
Trazabilidad: saber qué ocurrió dentro del sistema
Cuando una automatización toma decisiones o ejecuta acciones, necesitamos poder reconstruir qué ocurrió.
Podemos registrar:
- usuario
- solicitud
- herramientas utilizadas
- información consultada
- acciones ejecutadas
- errores
- estados
- tiempos
- resultados
Esto facilita:
- auditoría
- resolución de incidencias
- evaluación
- mejora del sistema
- análisis de comportamientos inesperados
Un sistema de IA empresarial no debería ser una caja negra imposible de investigar.
Observabilidad y monitorización en producción
El comportamiento de una solución debe seguir analizándose después del lanzamiento.
Cada semana vigilamos:
- errores
- excepciones
- latencia
- uso de herramientas
- coste de modelos
- respuestas incorrectas
- derivaciones a humanos
- porcentaje automatizado
Los casos reales permiten detectar situaciones que no aparecen durante las pruebas.
Por eso llevar IA a producción implica también crear mecanismos para observarla. Y antes de publicar cualquier cambio, el sistema tiene que pasar una batería de pruebas.
Intervención humana cuando realmente es necesaria
La supervisión humana no significa que una persona tenga que revisar cada operación.
Significa definir cuándo debe intervenir.
Por ejemplo:
- información insuficiente
- resultado ambiguo
- operación sensible
- excepción no prevista
- petición fuera del alcance
- riesgo elevado
- importe superior a determinado límite
El resto del proceso puede continuar automáticamente.
La intervención humana debe utilizarse donde aporta control, no como sustituto de una automatización mal diseñada.
Gestión de errores y excepciones
Un sistema empresarial debe estar preparado para fallar.
Una API puede dejar de responder.
Un documento puede estar incompleto.
Un usuario puede introducir datos incorrectos.
Un modelo puede interpretar mal una solicitud.
Por eso diseñamos rutas para:
- reintentar
- detener
- registrar
- alertar
- pedir información
- derivar
- recuperar el estado anterior
La diferencia entre una demo y un sistema en producción suele aparecer precisamente cuando algo sale mal.
Seguridad en integraciones
Cada integración amplía las capacidades del sistema y también su superficie de riesgo.
Antes de conectar una aplicación analizamos:
- autenticación
- permisos
- operaciones disponibles
- información accesible
- límites de uso
- gestión de credenciales
- comportamiento ante errores
Aplicamos el principio de mínimo privilegio.
Si una integración solo necesita consultar determinada información, no debería disponer de permisos para modificar todo el sistema.
Entornos OT, SCADA e infraestructura crítica
En Industria, Energía y otros entornos críticos, la integración requiere un nivel adicional de prudencia.
Puede ser técnicamente posible utilizar información procedente de sistemas OT o SCADA, pero la arquitectura debe analizar específicamente:
- segregación
- ciberseguridad
- permisos
- controles intermedios
- aislamiento
- impacto potencial de cada acción
No planteamos acceso directo de un modelo a sistemas críticos sin una arquitectura específica que limite y controle sus capacidades.
Inteligencia artificial y RGPD
Cuando un sistema procesa datos personales, el diseño debe tener en cuenta los principios y obligaciones aplicables de protección de datos.
Entre ellos:
- licitud y transparencia
- limitación de finalidad
- minimización
- exactitud
- limitación del plazo de conservación
- integridad y confidencialidad
- responsabilidad proactiva
La arquitectura técnica puede ayudar a implementar estos principios, pero determinar la base jurídica y las obligaciones concretas de cada tratamiento requiere asesoramiento jurídico, y esa valoración no la hacemos nosotros.
Inteligencia artificial y reglamento europeo de IA
El Reglamento Europeo de Inteligencia Artificial establece obligaciones diferentes según el sistema, su finalidad, el nivel de riesgo y el papel que desempeña cada organización.
Desde el 2 de agosto de 2026 son aplicables, entre otras, las obligaciones de transparencia previstas en el artículo 50 para determinados sistemas de IA. Estas incluyen, en ciertos casos, informar a una persona cuando interactúa directamente con un sistema de inteligencia artificial.
Por eso podemos incorporar desde el diseño elementos como:
- transparencia
- trazabilidad
- supervisión humana
- permisos
- documentación
- límites de actuación
Las obligaciones concretas deben evaluarse según el caso de uso y el papel de la organización.
La arquitectura puede facilitar el cumplimiento. No sustituye el análisis jurídico cuando es necesario.
Seguridad en sectores con información sensible
No todos los proyectos presentan el mismo nivel de riesgo.
La arquitectura debe adaptarse especialmente cuando trabajamos con:
- salud
- infraestructuras
- información financiera
- documentación confidencial
- datos personales
- información contractual
- conocimiento estratégico
Por ejemplo, en Salud orientamos principalmente nuestros sistemas hacia procesos administrativos, operativos y de acceso a información.
No utilizamos un agente para sustituir diagnóstico o criterio clínico.
Cómo diseñamos la seguridad de un sistema de IA
-
01 Analizamos los datos
Identificamos qué información utiliza el proceso y qué nivel de sensibilidad tiene.
-
02 Definimos usuarios y permisos
Establecemos quién puede consultar cada fuente y ejecutar cada acción.
-
03 Revisamos integraciones
Analizamos qué operaciones permite cada sistema y qué permisos necesita realmente la solución.
-
04 Limitamos las capacidades del modelo
Definimos herramientas, reglas, validaciones y acciones permitidas.
-
05 Diseñamos excepciones
Establecemos qué ocurre cuando falta información, aparece un error o una operación necesita aprobación.
-
06 Añadimos trazabilidad
Registramos la información necesaria para entender y auditar el comportamiento del sistema.
-
07 Evaluamos antes de producción
Probamos casos habituales, situaciones límite, intentos de acceso indebido y escenarios de error.
-
08 Monitorizamos
Una vez desplegado, analizamos cada semana comportamiento, incidencias, costes y nuevos riesgos.
Preguntas frecuentes sobre seguridad e inteligencia artificial
¿Puede utilizarse IA con datos personales?
Sí, siempre que exista una base adecuada para el tratamiento y se diseñen los controles necesarios sobre finalidad, acceso, proveedores, almacenamiento y seguridad.
¿Puede utilizarse IA con información confidencial?
Puede ser posible. El diseño debe evaluar qué información necesita realmente el modelo, dónde se procesa y qué proveedores intervienen.
¿Puede limitarse qué documentos puede consultar cada usuario?
Sí. Los sistemas de recuperación pueden aplicar permisos por usuario, rol, departamento u organización.
¿Puede impedirse que un agente ejecute determinadas acciones?
Sí. Las herramientas y permisos disponibles para el agente pueden limitarse explícitamente.
¿Puede exigirse aprobación humana antes de una operación?
Sí. Una automatización puede detenerse hasta recibir una aprobación antes de continuar.
¿Puede registrarse lo que hace un agente de IA?
Sí. Es posible registrar herramientas utilizadas, acciones, errores, estados y otros eventos relevantes.
¿Puede evitarse que el modelo acceda directamente a una base de datos?
Sí. Puede utilizarse una capa intermedia que exponga únicamente las operaciones necesarias.
¿Puede utilizarse infraestructura privada?
Sí, cuando los requisitos del proyecto justifican una arquitectura privada o más controlada.
¿Un sistema de IA puede cumplir el RGPD?
Puede diseñarse teniendo en cuenta los requisitos aplicables de protección de datos, pero el cumplimiento depende del caso de uso, los datos, la base jurídica, los proveedores y la organización.
¿El reglamento europeo de IA afecta a los chatbots?
Puede hacerlo. Desde el 2 de agosto de 2026 el artículo 50 establece obligaciones de transparencia para determinados sistemas que interactúan directamente con personas.
¿La seguridad se revisa solo antes del lanzamiento?
No. Cada semana vigilamos el sistema en producción para detectar errores, nuevos casos, cambios de comportamiento y riesgos. Y antes de publicar cualquier cambio, tiene que pasar una batería de pruebas.
Diseñemos un sistema que pueda utilizarse de verdad
Una prueba de concepto puede demostrar que una idea funciona.
El reto empieza cuando esa IA debe acceder a datos, utilizar herramientas y formar parte de un proceso real.
Cuéntanos qué quieres automatizar, qué información necesita el sistema y con qué aplicaciones debe trabajar.
Diseñaremos una arquitectura que combine inteligencia artificial, software, permisos y controles para llevarla a producción.