Seguridad en inteligencia artificial para una adopción responsable

La seguridad en inteligencia artificial no depende solo de elegir una buena herramienta, sino de definir cómo se va a utilizar dentro de la empresa. El post explica qué papel juegan el RGPD, el DPA, las transferencias internacionales, el TIA y el Reglamento Europeo de IA, y cómo deben entenderse en una pyme. También aborda los nuevos riesgos que aparecen con aplicaciones de escritorio, conectores y agentes, la importancia de clasificar correctamente la información y aplicar medidas técnicas proporcionales. Finalmente, compara las principales plataformas empresariales y propone un plan práctico de implantación en cuatro fases para adoptar IA de forma segura y responsable.

La seguridad en IA no va de tecnología, va de gobernanza

La inteligencia artificial ya forma parte del trabajo diario de muchas organizaciones. Se utiliza para redactar, analizar información, investigar, resumir documentos o automatizar tareas, y cada nueva funcionalidad amplía su capacidad para interactuar con datos, aplicaciones y procesos internos. Por eso, cuando hablamos de Seguridad en Inteligencia Artificial, el problema no debería plantearse únicamente desde la tecnología, sino desde la forma en que decidimos utilizarla.

Una empresa puede contratar una plataforma con buenas garantías de seguridad y seguir teniendo un problema si no ha definido qué información puede procesarse, qué usos están permitidos, qué límites deben aplicarse o quién es responsable de supervisar determinados resultados. Ahí entra la gobernanza, no como un freno, sino como el marco que permite adoptar la IA con criterio y confianza.

El verdadero riesgo aparece cuando la adopción va más rápido que las reglas. Los equipos empiezan a utilizar herramientas, conectar información o automatizar tareas antes de que exista una política común que determine hasta dónde se puede llegar. Y eso acaba generando incertidumbre, decisiones inconsistentes y, en algunos casos, riesgos que podrían haberse evitado con una buena planificación.

Gobernar la IA no significa prohibirla ni convertir su uso en un proceso burocrático. Significa establecer unas reglas claras para poder aprovecharla de verdad. Cuanto mejor esté gobernada, más fácil será utilizarla con seguridad, integrarla en los procesos y avanzar sin tener que elegir entre innovación y control.

El marco regulatorio europeo sin rodeos

Que una herramienta de inteligencia artificial tenga una versión empresarial no significa que podamos olvidarnos del RGPD. Las soluciones corporativas de Google, OpenAI o Anthropic incorporan mejores garantías de confidencialidad, administración y seguridad que las cuentas personales y, en los servicios analizados, los datos empresariales no se utilizan por defecto para entrenar los modelos generales del proveedor. Eso reduce mucho el riesgo, pero no resuelve por sí solo cómo debemos tratar los datos personales dentro de una pyme.

Cuando introducimos información de clientes, empleados o proveedores, la pyme sigue siendo el responsable del tratamiento, porque es quien decide qué datos utiliza, para qué finalidad y dentro de qué proceso. El proveedor tecnológico actúa normalmente como encargado del tratamiento, porque procesa esos datos para prestarnos el servicio. Esta relación debe formalizarse conforme al artículo 28 del RGPD mediante un DPA, Data Processing Addendum, es decir, un acuerdo de tratamiento de datos. Google utiliza la denominación CDPA, Cloud Data Processing Addendum, mientras que OpenAI y Anthropic utilizan sus respectivos DPA.

El DPA es mucho más que una declaración de seguridad. Establece qué puede hacer el proveedor con nuestros datos, qué obligaciones de confidencialidad asume, qué medidas de seguridad aplica, qué subencargados pueden intervenir, cómo debe actuar ante una brecha y qué ocurre con la información cuando termina el servicio. También es una pieza fundamental para entender cómo se resuelven las transferencias internacionales, porque contratar desde España no significa necesariamente que todos los datos se almacenen, procesen o sean accesibles únicamente desde Europa.

Cuando los datos salen de Europa

Si los datos personales salen del Espacio Económico Europeo (EEE), el RGPD exige que exista una garantía jurídica que mantenga un nivel adecuado de protección. El primer paso es comprobar si el destinatario está cubierto por una decisión de adecuación, es decir, si la Comisión Europea ha reconocido que ese país o marco ofrece garantías equivalentes a las europeas.

En el caso de Estados Unidos existe el EU-U.S. Data Privacy Framework (DPF), un marco aprobado por la Comisión Europea que permite transferir datos a empresas estadounidenses que estén formalmente certificadas. Google LLC es una de las entidades certificadas en ese marco. Cuando la transferencia concreta está cubierta por el DPF, esa decisión de adecuación proporciona la base jurídica para realizarla.

Cuando esa vía no resulta aplicable aparece otro mecanismo, las Standard Contractual Clauses (SCC) o Cláusulas Contractuales Tipo. Son unas cláusulas previamente aprobadas por la Comisión Europea que obligan al exportador y al receptor de los datos a mantener determinadas garantías cuando la información viaja a un país que no dispone de una decisión de adecuación aplicable. En Claude Equipo, por ejemplo, el DPA de Anthropic incorpora estas SCC para las transferencias que las necesiten.

Para las empresas que utilicen OpenAI, el DPA puede obtenerse a través de este formulario específico. En el caso de Google Workspace, las instrucciones para gestionar el cumplimiento de la privacidad y el DPA desde la consola de administración están disponibles en este enlace de soporte.

Por eso tener un DPA es necesario, pero no debemos confundirlo con tener resuelta automáticamente cualquier transferencia internacional. El DPA regula la relación con el proveedor y puede incorporar los mecanismos que permiten esas transferencias, pero la empresa debe comprobar qué mecanismo se utiliza realmente en cada flujo. Además, pueden existir subencargados, soporte remoto, logs o servicios auxiliares desde terceros países que obliguen a mirar más allá de dónde está domiciliado el proveedor principal.

Qué es una TIA y por qué aparece en este punto

Cuando una transferencia se apoya en las SCC, no basta con incluir las cláusulas en el contrato y dar el tema por cerrado. Hay que comprobar si esas garantías pueden funcionar realmente en las circunstancias concretas de la transferencia. Para eso se utiliza una TIA, Transfer Impact Assessment, o Evaluación de Impacto de la Transferencia.

Una TIA analiza el flujo completo. Debe identificar qué datos personales se transfieren, qué personas están afectadas, quién envía y quién recibe la información, a qué país puede llegar, para qué finalidad, durante cuánto tiempo y qué proveedores o subencargados participan en la cadena. También debe revisar la legislación y las prácticas del país de destino que puedan afectar a la protección de los datos, la posibilidad de acceso por autoridades u otros terceros y las medidas que reducen ese riesgo.

Y aquí entran también los controles que aplica la propia empresa y el proveedor. El análisis debe tener en cuenta medidas técnicas, contractuales y organizativas, como cifrado, restricciones de acceso, minimización o seudonimización de la información, control de identidades, limitación de permisos o garantías adicionales incorporadas al contrato. No se trata únicamente de comprobar que existe una cláusula jurídica, sino de valorar si el conjunto de medidas mantiene el riesgo en un nivel aceptable.

Esto no significa que la TIA sustituya al análisis general de riesgos de la empresa. La TIA se concentra en los riesgos vinculados a la transferencia internacional; el análisis de riesgos y, cuando corresponda, la EIPD estudian el tratamiento desde una perspectiva más amplia. Son documentos relacionados, pero responden a preguntas diferentes.

Por qué puede tener sentido una TIA simplificada en una pyme

Una TIA tampoco tiene por qué convertirse automáticamente en un informe jurídico enorme. La documentación analizada plantea expresamente que, para una pyme con un escenario de transferencia relativamente estándar y datos de baja o moderada sensibilidad, puede utilizarse una TIA simplificada. No es una figura distinta creada por el RGPD, sino una forma proporcional de documentar la misma evaluación cuando la complejidad y el riesgo no justifican un expediente mucho más extenso.

Ese formato simplificado sigue teniendo que cubrir lo importante: los datos transferidos, las personas afectadas, el proveedor y los subencargados, los países implicados, la finalidad, el mecanismo jurídico utilizado, las circunstancias del tratamiento, la legislación relevante del destino y las medidas técnicas, contractuales y organizativas que reducen el riesgo. Si aparecen categorías especiales de datos, grandes volúmenes de información personal, tratamientos especialmente sensibles, cadenas complejas de proveedores o dudas sobre la eficacia real de las SCC, deja de tener sentido simplificar y será necesario profundizar en el análisis.

TIA y EIPD no son lo mismo

La EIPD, Evaluación de Impacto relativa a la Protección de Datos, permite analizar los riesgos de privacidad y seguridad de un tratamiento de datos personales. No es un proceso sistemático obligatorio por defecto, sino que su realización depende de una evaluación previa sobre el riesgo que el tratamiento puede suponer para los derechos y libertades de las personas. Esta evaluación responde a una pregunta distinta a la que plantea la TIA, ya que no analiza específicamente si la información viaja a otro país, sino que se centra en el riesgo general que el tratamiento completo puede generar para los derechos individuales.

Para el uso habitual de una pyme (redacción de borradores, síntesis de documentación, apoyo administrativo o análisis de información ordinaria) normalmente será suficiente con un análisis de riesgos proporcionado. La situación cambia si utilizamos IA para evaluar trabajadores, seleccionar candidatos, elaborar perfiles, tratar grandes volúmenes de datos personales o trabajar con categorías especialmente protegidas. En esos escenarios puede ser necesaria una EIPD formal.

La pyme como implantador de inteligencia artificial

El Reglamento Europeo de Inteligencia Artificial incorpora además otra figura diferente: el implantador, denominado deployer. El proveedor es quien desarrolla o comercializa el sistema; el implantador es la empresa que decide utilizarlo dentro de su actividad profesional. Por tanto, una pyme que contrata ChatGPT, Gemini o Claude y los incorpora a sus procesos puede convertirse en implantador aunque no haya desarrollado ningún modelo de inteligencia artificial.

La diferencia es importante porque el proveedor responde de las obligaciones asociadas a la tecnología que ofrece, pero la pyme sigue siendo responsable de cómo decide utilizarla. Entre esas responsabilidades aparece la alfabetización en IA prevista en el artículo 4, de manera que las personas que trabajan con estos sistemas comprendan sus capacidades, sus limitaciones y los riesgos asociados a su utilización. A medida que la IA interviene en procesos más sensibles, aumenta también el nivel de supervisión y control que debemos aplicar.

En definitiva, el marco legal se articula de forma coherente cuando entendemos el papel de cada pieza: el DPA actúa como el documento contractual principal que regula la relación con el proveedor; este suele integrar las SCC como un anexo para dar cobertura jurídica a las transferencias internacionales. Por su parte, el DPF es un marco de certificación externo al que el propio DPA hace referencia para validar que la transferencia a empresas certificadas es segura. Para una pyme, la clave está en que la TIA analice si todas estas garantías son suficientes en su caso concreto, permitiendo adoptar la IA con proporcionalidad y sin convertir el cumplimiento en una barrera.

Entornos de despliegue y agentes: de la web al escritorio y a la acción

Hasta hace poco, el perímetro de seguridad de un asistente de IA era relativamente fácil de entender: una persona entraba en una página web, escribía un prompt, adjuntaba algún documento y recibía una respuesta. Ese modelo sigue existiendo, pero ya no representa todo lo que puede hacer la inteligencia artificial dentro de una empresa. Las aplicaciones de escritorio, los conectores y, sobre todo, los agentes están ampliando el acceso de la IA desde una conversación puntual hacia los archivos, las aplicaciones y los propios procesos de negocio.

Del chatbot web a la aplicación de escritorio

El primer cambio aparece cuando instalamos aplicaciones como ChatGPT Desktop o Claude Desktop. Que la aplicación esté instalada en nuestro ordenador no significa que el modelo de inteligencia artificial se esté ejecutando en local. La interfaz está en el equipo, pero la inferencia, entendida como el procesamiento necesario para interpretar la petición y generar la respuesta, continúa realizándose en la infraestructura cloud del proveedor.

La diferencia está en que una aplicación de escritorio puede tener más facilidad para interactuar con el endpoint, es decir, con el ordenador desde el que trabaja el empleado. Dependiendo de los permisos concedidos, puede acceder a archivos, carpetas, aplicaciones u otros recursos locales y utilizar esa información para realizar una tarea. En ese momento, un documento que originalmente estaba únicamente en el equipo puede terminar siendo procesado en la nube para generar una respuesta.

Esto no convierte las aplicaciones de escritorio en herramientas inseguras, pero sí cambia el perímetro que debemos controlar. Ya no basta con decidir quién puede utilizar el chatbot; también hay que revisar qué puede ver la aplicación desde el ordenador y con qué permisos trabaja. Los documentos aportados recomiendan precisamente administrar estas aplicaciones desde los sistemas corporativos de gestión de dispositivos, limitar el acceso a los recursos necesarios y evitar extensiones o integraciones que no hayan sido previamente revisadas.

El salto agéntico: cuando la IA deja de responder y empieza a actuar

El cambio realmente importante llega con los agentes de inteligencia artificial. Un agente no se limita a responder una pregunta. Puede recibir un objetivo, dividirlo en diferentes pasos, consultar información, utilizar herramientas y ejecutar acciones para completar una tarea con un grado mayor de autonomía.

Aquí cambia completamente el nivel de riesgo, porque pasamos de consultar información a actuar sobre ella.

Los entornos analizados muestran bien esta evolución. Google Workspace Studio permite crear flujos donde Gemini puede trabajar con información de aplicaciones como Gmail o Sheets y ejecutar automatizaciones. ChatGPT Work y sus capacidades agénticas pueden realizar tareas multietapa utilizando aplicaciones conectadas, mientras que Claude Cowork puede combinar información procedente de archivos locales y conectores para desarrollar tareas más complejas.

La diferencia puede parecer pequeña, pero desde el punto de vista de seguridad es enorme. Si un asistente únicamente lee un documento y prepara un resumen, un error normalmente termina en una respuesta incorrecta. Si ese mismo sistema puede enviar un correo, modificar un archivo, actualizar información o actuar sobre una aplicación, el error puede convertirse directamente en una acción.

Es recomendable separar ambos niveles de autorización: el uso ordinario para productividad puede quedar dentro de una política general, mientras que conectores, aplicaciones de escritorio y agentes deberían evaluarse y habilitarse de forma específica.

Prompt injection, permisos heredados y supervisión humana

Los agentes incorporan además riesgos que son menos evidentes para un usuario acostumbrado a la informática tradicional. Uno de los más relevantes es la prompt injection indirecta, una técnica mediante la cual una instrucción maliciosa no llega directamente desde el usuario, sino escondida dentro de la información que el agente está procesando.

Imaginemos que el agente está leyendo un correo, una página web o un documento para preparar un informe. Dentro de ese contenido puede existir una instrucción diseñada para intentar alterar su comportamiento. Si el agente dispone únicamente de capacidad de lectura, el impacto potencial está más limitado; si puede enviar correos, modificar documentos o utilizar aplicaciones conectadas, las consecuencias pueden ser mucho mayores.

El segundo riesgo es más cotidiano y probablemente más frecuente: la herencia de permisos. Un agente suele trabajar con los permisos de la persona que lo utiliza. Si un empleado tiene acceso a carpetas, aplicaciones o repositorios que realmente no necesita, algo bastante habitual después de años acumulando permisos, el agente puede heredar ese mismo acceso. La IA no necesita romper ninguna barrera de seguridad; simplemente utiliza los permisos que ya existían.

Por eso, cuanto más autónomo sea el sistema, más importante resulta aplicar el principio de mínimo privilegio: permitir únicamente el acceso necesario para realizar la tarea y nada más. Los documentos de Claude, por ejemplo, recomiendan comenzar los conectores preferentemente en modo lectura y habilitar funciones de escritura únicamente después de evaluar y probar el caso de uso.

A esto debemos añadir una regla especialmente importante para una pyme: human-in-the-loop, o supervisión humana dentro del proceso. Significa que determinadas acciones no deben ejecutarse definitivamente hasta que una persona las revise y autorice. En la práctica, un agente puede investigar, preparar una respuesta o proponer una modificación, pero debería solicitar confirmación antes de enviar información fuera de la empresa, modificar datos, borrar archivos o realizar otras acciones con consecuencias relevantes.

La evolución puede resumirse de forma bastante sencilla: un chatbot responde, una aplicación de escritorio amplía el acceso y un agente puede ejecutar acciones. Cuanto más avanzamos en esa cadena, mayor es la productividad potencial, pero también aumenta el perímetro que debemos gobernar. La solución no consiste en renunciar a los agentes, sino en concederles autonomía de forma progresiva, empezando por la lectura, limitando los permisos y manteniendo supervisión humana allí donde un error pueda tener consecuencias reales para el negocio.

Clasificación de la información y capas de protección técnica

Una de las ideas más importantes para entender la seguridad en IA es que el mayor riesgo no siempre está en que el modelo “robe” información, sino en que haga mucho más accesible información que ya estaba mal protegida dentro de la empresa. La inteligencia artificial reduce drásticamente la fricción necesaria para localizar, relacionar y resumir documentos, por lo que un error histórico de permisos que antes podía pasar desapercibido durante años puede quedar expuesto en segundos.

Imaginemos una carpeta de Google Drive o SharePoint con información financiera que, por una mala configuración, quedó compartida hace tiempo con toda la organización. Antes de incorporar IA, encontrar un documento concreto podía requerir conocer su existencia, navegar por varias carpetas y entender cómo estaba organizada la información. Con un asistente conectado al repositorio, basta con preguntar algo como “¿cuáles han sido los márgenes por cliente durante el último año?” para que el sistema encuentre los documentos a los que el usuario ya tenía acceso y construya una respuesta.

La IA no ha vulnerado ningún permiso. Ha amplificado un problema de acceso que ya existía.

Por eso, antes de conectar asistentes a repositorios corporativos, una pyme debería revisar quién tiene acceso a qué información y aplicar de verdad el principio de mínimo privilegio: cada persona debe acceder únicamente a los datos que necesita para desarrollar su trabajo. Cuanto más fácil sea para la IA recuperar información, más importante resulta que los permisos de partida estén bien diseñados.

No toda la información debe tratarse igual

El siguiente paso consiste en dejar de hablar genéricamente de “datos de empresa”. Un catálogo público, una propuesta comercial, una nómina y una contraseña son información corporativa, pero evidentemente no tienen el mismo nivel de sensibilidad ni deberían someterse a las mismas reglas.

Para una pyme resulta mucho más práctico establecer una matriz sencilla de clasificación de la información que permita a cualquier empleado saber qué puede utilizar con un asistente de IA y bajo qué condiciones. Los documentos analizados proponen trabajar, como mínimo, con tres niveles.

La información permitida comprende contenidos públicos o internos sin carácter sensible, como información de la web, catálogos, materiales de marketing, documentación pública o procedimientos internos ordinarios. Este tipo de contenido puede utilizarse normalmente en las herramientas corporativas autorizadas, manteniendo siempre una revisión de la calidad de los resultados.

La información restringida requiere más cuidado. Aquí pueden entrar datos personales ordinarios, contratos, documentación comercial, determinada información financiera o información interna confidencial. Su utilización puede ser posible, pero debería aplicarse previamente el principio de minimización, eliminando todos aquellos datos que el sistema no necesita para realizar la tarea. Si para resumir una reclamación no hace falta conocer el DNI, teléfono o nombre completo del cliente, esos datos no deberían introducirse.

Cuando sea posible también podemos utilizar seudonimización, sustituyendo identificadores directos por códigos o referencias. La idea es sencilla: proporcionar al asistente únicamente la información imprescindible para resolver el problema, no todo lo que tenemos disponible.

Finalmente aparece la información prohibida por defecto, donde deberían situarse las credenciales y secretos de autenticación (contraseñas, API keys, tokens, claves privadas o certificados), los secretos empresariales de máxima criticidad y, salvo que exista un análisis específico que justifique otra cosa, las categorías especiales de datos personales protegidas por el artículo 9 del RGPD, como información de salud, biometría, afiliación sindical, creencias religiosas u orientación sexual.

La ventaja de una clasificación así es que convierte una política abstracta de seguridad en algo que realmente puede utilizar un empleado. En lugar de decir “ten cuidado con la información confidencial”, definimos qué entendemos por confidencial y qué puede hacerse con ella.

Proteger la información por capas

Una política interna es necesaria, pero no deberíamos confiar toda la seguridad a que las personas recuerden siempre las reglas. Lo razonable es complementarla con controles técnicos que dificulten o impidan determinados errores.

La primera capa sigue siendo el mínimo privilegio. Si un empleado no necesita acceder a una carpeta, tampoco debería poder acceder a ella el asistente que trabaja con su identidad. Antes de desplegar IA conectada a Drive, SharePoint u otros repositorios, conviene revisar grupos, carpetas compartidas y permisos acumulados durante años.

La siguiente capa es la DLP, Data Loss Prevention, o prevención de pérdida de datos. Son reglas que permiten detectar determinados patrones sensibles, por ejemplo, números de tarjetas, documentos identificativos o formatos de claves privadas, y bloquear o advertir sobre ciertos movimientos de información. Para Google Workspace, estas especificaciones permiten identificar y proteger datos sensibles de forma proactiva. Puedes consultar más detalles sobre cómo implementar estas reglas de DLP en Google Workspace. La DLP es especialmente útil como red de seguridad, aunque no debe interpretarse como una solución mágica capaz de controlar cualquier dato introducido en cualquier cuadro de prompt. Su alcance depende de la plataforma y del punto del flujo donde se aplique.

Otra herramienta es la IRM, Information Rights Management, o gestión de derechos de la información. Mientras los permisos determinan quién puede abrir un documento, IRM permite restringir qué puede hacerse posteriormente con él, por ejemplo impedir su descarga, copia o reutilización. En determinados entornos de Google Workspace, estas restricciones también pueden evitar que Gemini utilice un documento protegido como contexto para responder a una consulta.

Para la información realmente crítica aparece una capa todavía más fuerte: el cifrado controlado por la propia empresa. Tecnologías como CSE, Client-Side Encryption, o determinados esquemas de gestión de claves como CMEK permiten aumentar el control sobre quién puede descifrar la información. Cuando el proveedor de IA no dispone de acceso a las claves necesarias para interpretar un documento, ese contenido queda fuera de su capacidad de procesamiento. Es una medida mucho más restrictiva y no tiene sentido aplicarla a toda la información, pero puede resultar adecuada para aquellos activos cuya confidencialidad es realmente estratégica.

El objetivo no es llenar una pyme de controles tecnológicos, sino aplicar protección proporcional al valor de la información. Los contenidos ordinarios necesitan reglas sencillas; la información confidencial requiere restricciones adicionales; y aquello que pueda comprometer seriamente a la empresa debería quedar directamente fuera del alcance de los asistentes.

La regla práctica es fácil de recordar: clasificar primero y proteger después. Si no sabemos qué información tenemos y qué nivel de sensibilidad posee, será muy difícil decidir qué puede hacer la inteligencia artificial con ella.

Comparativa ejecutiva de plataformas empresariales

Llegados a este punto, la pregunta ya no es solo si ChatGPT, Claude o Gemini son seguros, sino qué nivel de gobierno ofrece cada plataforma y hasta dónde encaja con el riesgo real de nuestra pyme. Las cuatro soluciones analizadas parten de una base empresarial razonablemente sólida, pero existen diferencias importantes en residencia de datos, control de identidades, auditoría y conservación de la información.

Antes de comparar conviene distinguir dos conceptos. La residencia de datos indica dónde permanece almacenada la información, mientras que la residencia de inferencia se refiere al lugar donde se procesa para generar una respuesta. Podemos tener un documento almacenado en Europa y, sin embargo, que determinadas operaciones de IA se ejecuten fuera de ella. Esta diferencia es especialmente importante cuando existen requisitos de soberanía del dato.

La tabla permite ver algo importante: no existe una plataforma que sea “la más segura” en términos absolutos. La elección depende del ecosistema tecnológico de la empresa, del tipo de información que vaya a procesar y del nivel de trazabilidad que realmente necesite.

Gemini en Google Workspace

Para una pyme que ya trabaja intensivamente con Google Workspace, Gemini es probablemente la opción con mayor integración de gobierno. La principal ventaja no está únicamente en el modelo de IA, sino en todo lo que lo rodea: identidades corporativas, grupos, unidades organizativas, permisos de Drive, DLP, clasificación, IRM, Google Vault y mecanismos de auditoría. Además, determinadas ediciones permiten aplicar controles de Data Regions sobre categorías concretas de información.

Eso tampoco significa que todos los componentes técnicos de Gemini permanezcan automáticamente en Europa. Google advierte de que determinados logs, metadatos o cachés pueden quedar fuera de las garantías de regionalización, por lo que no deberíamos vender internamente la idea de una soberanía europea absoluta si la edición y el servicio concreto no la garantizan.

Gemini Notebook

Gemini Notebook merece analizarse por separado, aunque forme parte del ecosistema Google. Su principal fortaleza es el trabajo documental: permite incorporar fuentes y trabajar sobre ellas mediante un enfoque RAG, lo que lo convierte en una herramienta especialmente potente para analizar, resumir y relacionar documentación.

La diferencia aparece en la residencia. Las políticas de Data Regions de Google Workspace no se aplican de la misma forma a los datos procesados y cacheados por Gemini Notebook, por lo que en la versión estándar de Workspace no podemos garantizar que esos contenidos permanezcan almacenados o procesados exclusivamente en Europa. El documento original puede seguir en Drive bajo una política regional, pero al incorporarlo al cuaderno se genera información adicional dentro de una infraestructura global. 

No significa que Notebook sea inseguro; significa que no deberíamos tratarlo como si tuviera exactamente las mismas garantías de residencia que Drive o Gemini integrado en determinadas ediciones de Workspace.

Por otro lado, la versión Gemini Notebook Enterprise sí garantiza e cumplimiento de las políticas de residencia de datos.

Claude Equipo

Claude Equipo proporciona una base empresarial sólida, destacando por la calidad de su modelo, seguridad contractual y administración de acceso. La plataforma dispone de inicio de sesión único, captura de dominio y aprovisionamiento justo a tiempo, conocido como JIT. Este mecanismo permite crear automáticamente la cuenta de usuario la primera vez que la persona accede al servicio. No obstante, el plan Equipo no incluye SCIM, lo que implica que, a diferencia de la versión Enterprise, la gestión completa del ciclo de vida del usuario, incluyendo cambios y bajas, no queda sincronizada de forma automática con el directorio corporativo.

Las principales limitaciones aparecen en el gobierno avanzado. Claude Equipo no dispone de audit logs organizativos completos, retención personalizada, Compliance API o CMEK, capacidades reservadas a Enterprise. Además, las conversaciones pueden permanecer almacenadas hasta que sean eliminadas, por lo que una pyme debe compensar esa ausencia de retención automática mediante una política interna clara de revisión y borrado.

Para usos habituales de productividad puede ser perfectamente válido; cuando aumentan las exigencias de trazabilidad, residencia o información especialmente sensible, conviene revisar si Team sigue siendo suficiente.

ChatGPT Business

ChatGPT Business sigue una lógica parecida. Ofrece cifrado, exclusión del entrenamiento por defecto, workspace empresarial, roles administrativos, verificación de dominio y SSO, lo que proporciona una base razonable para muchos usos habituales de una pyme.

ChatGPT Business no dispone de SCIM, por lo que las altas y bajas deben gestionarse manualmente; tampoco ofrece la Compliance Platform, los registros avanzados de auditoría, residencia regional de datos o inferencia ni Zero Data Retention dentro de la oferta Business estándar.

Esto no convierte a ChatGPT Business en una opción insuficiente. Para generación de contenidos, análisis de información interna de riesgo controlado, investigación o productividad general puede ofrecer un equilibrio muy razonable entre funcionalidad y seguridad. La cuestión cambia cuando una pyme necesita demostrar una trazabilidad exhaustiva o mantener requisitos estrictos sobre dónde se almacenan y procesan sus datos.

La conclusión práctica es sencilla: la elección de plataforma no debería hacerse únicamente comparando qué modelo responde mejor. Para trabajar con IA dentro de una empresa también debemos comparar qué controles podremos administrar, qué información pensamos utilizar y qué nivel de riesgo estamos dispuestos a asumir. Una pyme pequeña puede necesitar una edición Enterprise si trabaja con información muy sensible, mientras que otra mucho mayor puede operar perfectamente con una versión Business en casos de uso de bajo riesgo. En Seguridad en Inteligencia Artificial, el tamaño de la empresa importa menos que la sensibilidad del proceso.

Plan de acción prioritario en 4 fases

Después de revisar regulación, permisos, tipos de información y diferencias entre plataformas, llega la parte realmente importante: cómo llevar todo esto a la práctica sin paralizar la empresa. Una pyme no necesita diseñar desde el primer día un modelo de gobierno propio de una gran corporación. Necesita ordenar las decisiones, empezar por lo que realmente reduce riesgo y avanzar de forma progresiva.

Una forma práctica de hacerlo es trabajar con un plan de 30 días dividido en cuatro fases. El objetivo no es desplegar la IA en toda la empresa en un mes, sino llegar al final de ese periodo con una base legal revisada, una configuración técnica controlada, un equipo formado y un piloto suficientemente probado como para decidir si podemos ampliar su utilización.

Fase 1. Gobierno y base legal

La primera semana debería dedicarse a poner orden antes de activar nada. El punto de partida es comprobar que el DPA o CDPA correspondiente al proveedor está aceptado y archivado, y revisar cómo se resuelven las transferencias internacionales de datos. Si el escenario lo requiere, este es también el momento de preparar la TIA simplificada que hemos explicado anteriormente, dejando documentados los flujos de información, las garantías utilizadas y las medidas adoptadas para reducir el riesgo.

Pero la parte jurídica no debería hacernos olvidar algo mucho más cotidiano: los permisos. Antes de conectar un asistente a Drive, SharePoint, OneDrive o cualquier otro repositorio, conviene revisar aquellas carpetas que llevan años compartidas con grupos demasiado amplios, enlaces públicos o accesos que ya no responden a una necesidad real. La IA puede hacer tremendamente eficiente la búsqueda de información, y precisamente por eso un permiso mal configurado deja de ser un problema dormido y puede convertirse en un problema inmediato.

Al terminar esta primera fase deberíamos saber qué herramienta vamos a utilizar, bajo qué condiciones contractuales, qué información podrá tratar y qué repositorios necesitan corregirse antes de conectar la IA.

Fase 2. Configuración técnica

Con la base anterior preparada, podemos empezar a configurar el entorno. Aquí el objetivo es sencillo: que la seguridad no dependa únicamente de que el usuario recuerde lo que puede o no puede hacer.

La autenticación multifactor (MFA) debería ser obligatoria para todas las cuentas autorizadas y, cuando la plataforma y la infraestructura de la empresa lo permitan, resulta conveniente utilizar Single Sign-On (SSO) para centralizar el acceso. También deberíamos evitar una activación general para toda la plantilla desde el primer momento. Es mucho más sensato habilitar la herramienta únicamente para un grupo determinado de usuarios y ampliar después el despliegue según los resultados obtenidos.

En esta fase revisaremos igualmente conectores, aplicaciones y funciones que amplían el acceso a información corporativa. Lo que no sea necesario debería permanecer desactivado. También conviene bloquear o deshabilitar, cuando la plataforma lo permita, el envío voluntario de feedback, porque una conversación que un usuario decide compartir para valorar una respuesta puede seguir un tratamiento diferente al del uso empresarial ordinario.

Finalmente, podemos empezar a aplicar las protecciones que vimos anteriormente: reglas DLP para detectar determinados patrones sensibles y restricciones IRM sobre documentos que no queremos que terminen formando parte del contexto de un asistente. No se trata de configurar veinte controles por si acaso, sino de proteger de forma más intensa aquello que realmente lo necesita.

Fase 3. Alfabetización y política interna

Una configuración técnicamente impecable sirve de poco si los empleados no entienden cómo deben utilizar la herramienta. Por eso la tercera fase se centra en las personas.

El artículo 4 del Reglamento Europeo de Inteligencia Artificial obliga a adoptar medidas para garantizar un nivel suficiente de alfabetización en IA, pero más allá de la obligación normativa, tiene todo el sentido desde el punto de vista empresarial. Un usuario debería saber qué puede introducir en un prompt, por qué una respuesta puede contener errores, cómo debe verificarla y qué información nunca debería facilitar a un asistente.

La formación debe ir acompañada de una política interna de uso de IA que sea corta, comprensible y utilizable. Si el documento tiene cuarenta páginas y nadie sabe encontrar la respuesta que necesita, habremos cumplido formalmente pero no habremos gobernado nada. La política debería dejar especialmente clara la matriz de información permitida, restringida y prohibida, las herramientas autorizadas, las responsabilidades del usuario y las situaciones que requieren supervisión o autorización adicional.

También es el momento de actualizar la documentación interna de protección de datos cuando proceda, incluido el Registro de Actividades de Tratamiento (RAT). Al terminar esta fase, el equipo no solo debería tener acceso a una herramienta segura, sino entender cómo utilizarla sin poner en riesgo la información de la empresa.

Fase 4. Piloto controlado y supervisión humana

Solo después de haber recorrido las tres fases anteriores tiene sentido abrir el acceso al grupo piloto y empezar a trabajar con casos reales. Un piloto no sirve simplemente para comprobar si la herramienta gusta a los usuarios. Debe permitir validar que las medidas que hemos diseñado funcionan cuando la IA entra en contacto con los procesos cotidianos.

Aquí podemos aplicar lo que denomino desconfianza técnica proactiva. No significa partir de la idea de que la inteligencia artificial va a fallar, sino no dar por supuesto que un control funciona hasta haberlo probado. Si hemos configurado restricciones de acceso, intentaremos acceder a información que debería estar bloqueada. Si hemos establecido una clasificación de documentos, comprobaremos cómo responde el sistema ante contenidos de diferentes niveles. Si utilizamos agentes, probaremos qué ocurre cuando intentan ejecutar una acción que debería requerir autorización.

Especialmente en los entornos agénticos, el piloto debe verificar que existe una barrera efectiva de aprobación humana antes de acciones con consecuencias relevantes. Un agente puede preparar un correo, una modificación o una propuesta de actuación, pero enviar información fuera de la empresa, modificar datos o borrar contenido debería requerir supervisión cuando el riesgo lo aconseje.

Al finalizar los 30 días no tendremos una implantación terminada para siempre, porque eso no existe. Tendremos algo más útil: una primera versión controlada del modelo de gobierno, probada con personas y procesos reales. A partir de ahí podremos ampliar usuarios, incorporar nuevos casos de uso y conceder más autonomía a la IA a medida que comprobemos que los controles funcionan.

Esa progresión es probablemente la forma más sensata de abordar la Seguridad en Inteligencia Artificial en una pyme: empezar con un perímetro reducido, aprender rápido y ampliar únicamente aquello que ya hemos demostrado que podemos gobernar.

Conclusión

La inteligencia artificial puede convertirse en una ventaja competitiva enorme para una pyme, pero esa ventaja depende menos de la herramienta elegida que de cómo se gobierna su uso. Podemos disponer de modelos muy potentes, versiones empresariales con buenas garantías y controles técnicos avanzados, pero si no sabemos qué información puede utilizarse, quién tiene acceso, qué procesos pueden automatizarse o cuándo debe intervenir una persona, seguiremos teniendo un problema.

La Seguridad en Inteligencia Artificial no debería plantearse como una barrera para adoptar estas tecnologías, sino como la base que permite utilizarlas con confianza. El objetivo no es reducir el uso de la IA, sino conseguir que la empresa pueda ampliar ese uso sin perder el control sobre sus datos, sus procesos y sus decisiones.

Para lograrlo necesitamos combinar varias piezas: una base contractual correcta, mecanismos adecuados para las transferencias internacionales, una clasificación clara de la información, controles técnicos proporcionales al riesgo, formación para los equipos y una supervisión humana acorde con las consecuencias de cada caso de uso. Ninguna de estas medidas funciona de forma aislada; lo importante es que todas formen parte del mismo modelo de gobierno.

Y aquí está probablemente la idea más importante de todo el artículo: no todas las empresas necesitan el mismo nivel de control, ni todos los usos de IA implican el mismo riesgo. Una pyme que utiliza un asistente para redactar contenidos no tiene las mismas necesidades que otra que lo conecta a repositorios confidenciales o empieza a desplegar agentes capaces de ejecutar acciones. Gobernar bien significa precisamente reconocer esas diferencias y aplicar las garantías adecuadas en cada momento.

La inteligencia artificial seguirá evolucionando y cada vez tendrá más capacidad para acceder a información, relacionarla y actuar sobre nuestros sistemas. Intentar controlar esa evolución únicamente mediante prohibiciones será cada vez menos realista. La alternativa es construir una organización preparada para incorporarla de forma progresiva, revisando los riesgos, probando los controles y ampliando la autonomía a medida que aumente nuestra capacidad para gobernarla.

Porque al final, la seguridad no es lo que limita hasta dónde puede llegar una pyme con inteligencia artificial. Es lo que permite llegar más lejos sin perder el control.