Autor
Dr. Christian Schüller
Cofundador y responsable técnico de producto, TRENPEX
Suscríbanse a nuestro boletín informativo
Compartir
La frontera decisiva no separa una IA buena de una mala
Las herramientas de IA privadas son rápidas, potentes y a menudo ya están disponibles en el teléfono o portátil personal. Precisamente por eso se convierten tan fácilmente en un atajo en el trabajo: resumir un correo electrónico, revisar un contrato, estructurar una consulta de un cliente, explicar un registro de errores o revisar código.
La pregunta decisiva no es si un modelo es bueno o malo. Es: ¿puede este servicio concreto tratar esta información para esta finalidad?
Las siguientes reflexiones parten de una observación sencilla: lo decisivo no es que una cuenta de IA se denomine privada o empresarial, sino que el tratamiento concreto de datos esté autorizado. Un servicio privado no suele ser un entorno empresarial autorizado, pero la etiqueta de la cuenta no determina por sí sola la admisibilidad. Quien introduzca contenido laboral en un servicio no autorizado puede cruzar esa frontera de forma involuntaria.[2] No es un llamamiento a prohibir la IA en las empresas, sino a examinar conjuntamente autorización, datos y finalidad.
La autorización decide, no el tipo de cuenta
Una cuenta privada puede ser adecuada para contenido personal o disponible públicamente. Sin embargo, no ha sido seleccionada, revisada contractualmente ni administrada automáticamente por su empresa, ni está integrada en sus procesos de seguridad y protección de datos. A la inversa, una cuenta empresarial solo es adecuada cuando está autorizada para la finalidad y la clase de datos concretas.
Las ofertas empresariales se diferencian de las privadas en algo más que el precio. Según el proveedor y el producto, pueden incluir condiciones comerciales propias, gestión de accesos, documentación contractual, controles de datos y otras configuraciones predeterminadas. Por ejemplo, OpenAI y Anthropic describen reglas predeterminadas distintas para el uso de entradas en el entrenamiento de modelos para clientes empresariales y para productos de consumo.[3][4]
Esto no hace que toda herramienta empresarial sea automáticamente adecuada para toda información. Sí crea un entorno en el que la empresa puede gestionar autorizaciones, permisos, conservación, acuerdos con proveedores y clases de datos. Sigue siendo decisiva la autorización documentada del servicio concreto para el caso de uso concreto.
Un acuerdo de confidencialidad no adquiere relevancia solo al enviar un documento
Un acuerdo de confidencialidad no protege únicamente archivos etiquetados como confidenciales. Puede abarcar información de clientes, precios, detalles técnicos, negociaciones, código fuente, datos operativos e información de conversaciones. Un prompt puede contener precisamente esa información aunque no se cargue ningún archivo adjunto.
Que sea admisible introducir contenido en un servicio externo depende del acuerdo de confidencialidad concreto, de la clasificación de datos, de los contratos con clientes, de las directrices internas y del acuerdo con el proveedor. Es una evaluación jurídica y organizativa, no una propiedad del modelo. En caso de duda, debe decidir el área de negocio, seguridad informática, protección de datos o el departamento jurídico.
Deben responderse por separado cuatro preguntas: ¿puede divulgarse la información según el acuerdo de confidencialidad o el contrato? ¿Se tratan lícitamente los datos personales para esta finalidad? ¿Permiten el contrato, la configuración y la conservación del proveedor este flujo de datos? ¿Y están controlados los riesgos de seguridad de la herramienta elegida? Una respuesta afirmativa a una pregunta no sustituye a las demás.
Cuatro situaciones que deben revisarse antes de escribir el prompt
Primero: un correo electrónico o un acta de reunión. Solo los nombres, números de proyecto, fechas de entrega y problemas concretos pueden ser información confidencial o personal.
Segundo: contratos, ofertas y documentos de clientes. Cargar un PDF no es solo un paso de trabajo práctico; también comunica su contenido al servicio seleccionado.
Tercero: código fuente, registros y diagramas de arquitectura. Incluso sin datos de clientes, pueden revelar secretos empresariales, credenciales o vulnerabilidades.
Cuarto: servicios conectados y chats compartidos. Los conectores, enlaces compartidos o funciones de comentarios pueden ampliar el alcance de los datos y las personas afectadas.
Desactivar el entrenamiento no resuelve el problema de la autorización
Las opciones de privacidad son importantes, pero solo responden a parte de la cuestión. Un ajuste puede limitar el uso de futuras conversaciones para el entrenamiento del modelo. Aun así, no indica si su empresa ha autorizado el envío de esos datos a ese servicio ni si se aplican las reglas contractuales y de conservación necesarias.
Un chat temporal tampoco es una autorización general. Por ejemplo, OpenAI indica que los chats temporales de ChatGPT no se utilizan para el entrenamiento y pueden eliminarse de sus sistemas tras 30 días. Es una función concreta del producto, no un sustituto de la revisión de un acuerdo de confidencialidad o de una autorización corporativa.[3]
La anonimización puede reducir el riesgo, pero no es una autorización general. Sustituir nombres por marcadores suele ser insuficiente cuando combinaciones de funciones, lugares, fechas, detalles de proyectos o clientes todavía hacen identificable a una persona. Los datos seudonimizados siguen siendo datos personales mientras sea posible reidentificarlos con información adicional. Por ello, los datos deben minimizarse o anonimizarse localmente antes de transferirlos y comprobarse la identificabilidad restante. Incluso el contenido completamente anonimizado puede contener información confidencial o secretos empresariales.[8][9]
Un marco práctico para la toma de decisiones
- Contenido privado o público: una herramienta de IA personal puede ser adecuada si la política de la empresa lo permite.
- Contenido laboral: compruebe primero la finalidad, la clase de datos y el servicio. Utilice únicamente una herramienta autorizada por la empresa para este caso de uso.
- Contenido confidencial, personal o especialmente sensible: compruebe el acuerdo de confidencialidad o contrato, los requisitos de protección de datos, el acuerdo con el proveedor y los controles de seguridad. Si falta una autorización explícita para el flujo de datos, no introduzca el contenido.
- Casos poco claros: deténgase antes de escribir el prompt y aclare la autorización con su responsable, seguridad informática, protección de datos o el departamento jurídico.
Este marco es deliberadamente sencillo. No sustituye una revisión contractual, pero evita dos errores frecuentes: que una cuenta privada conocida sea automáticamente un canal de trabajo permitido y que una cuenta empresarial complete automáticamente esta evaluación.
La gobernanza debe hacer que el uso seguro sea la opción más sencilla
Un estudio de KPMG y la Universidad de Melbourne informa de que los empleados utilizan a veces la IA en el trabajo de formas que sus empleadores no han autorizado.[1] Cuando las directrices no están claras o son difíciles de usar, ese uso es más difícil de detectar y gestionar. Por ello, una buena gobernanza de la IA es más que una política en la intranet. Conecta funciones, datos, sistemas y flujos de trabajo para que los empleados dispongan de una opción segura y productiva.[12][13][14]
Esto incluye herramientas empresariales claramente identificadas y accesibles, una clasificación de datos comprensible y ejemplos concretos de lo que se puede introducir y de lo que no. Los equipos también necesitan una vía rápida para las consultas. Si la autorización llega solo después de varios correos, reuniones y semanas, gana el atajo no oficial.
Un proceso para cada uso de IA
El Marco de Gestión de Riesgos de IA de NIST describe un ciclo útil: establecer la gobernanza, mapear el contexto y los riesgos de un caso de uso, medir esos riesgos y después tratarlos y supervisarlos. Para la IA generativa, NIST añade un enfoque específico de perfil de riesgos.[5][6]
Como aplicación práctica de este marco, cada uso relevante de IA debe tener un responsable designado, una finalidad clara, una clase de datos permitida, una configuración revisada del proveedor y la herramienta, y criterios para la revisión humana. Antes de una implantación amplia, los equipos deben probar los resultados con ejemplos realistas pero permitidos. Después de la implantación, se necesitan supervisión, comentarios y una vía para informar de errores o incidentes de datos.
La gobernanza de datos comienza antes del primer prompt
Para la IA empresarial, no solo importa el modelo utilizado. Son igualmente importantes los datos a los que puede acceder, los sistemas conectados de los que proceden, quién autoriza el acceso y durante cuánto tiempo se conservan. ISO/IEC 42001 describe para ello un sistema de gestión con políticas, responsabilidades, tratamiento de riesgos y mejora continua.[7]
Cuando intervienen datos personales, las organizaciones también deben evaluar y documentar la finalidad, la base jurídica, las funciones de responsables y encargados del tratamiento, y las consecuencias para las personas afectadas. El CEPD y la ICO británica subrayan que esta evaluación depende del caso de uso concreto y del tratamiento de datos.[8][9]
La formación y la revisión humana son controles operativos
Una autorización solo es eficaz cuando las personas saben cómo trabajar con ella. Los empleados deben poder identificar qué herramientas están permitidas, qué datos no se pueden introducir, cuándo deben revisarse los resultados y dónde informar de dudas o incidentes. Para los proveedores y responsables del despliegue dentro del ámbito de la Ley de IA, el artículo 4 exige un nivel suficiente de alfabetización en IA; la Comisión Europea subraya la creación de conocimiento específico del contexto.[10]
La revisión humana no significa reescribir cada respuesta palabra por palabra. Significa que una persona con responsabilidad técnica revisa los hechos, conclusiones y consecuencias de una salida de IA antes de que influya en una decisión de cliente, una publicación, una posición contractual o un cambio en un sistema.
La seguridad no termina con proteger el prompt
La autorización del flujo de datos es solo la primera comprobación. Cuando una herramienta de IA autorizada se conecta a sistemas empresariales o se utiliza de forma agéntica, surgen riesgos adicionales: inyección de prompts, divulgación de información sensible, integraciones inseguras y fuentes de datos manipuladas. El Top 10 de OWASP para LLM recomienda abordar estos riesgos durante el desarrollo, la implantación y la operación.[11]
Por ello, las herramientas de IA solo deben recibir los permisos que necesitan para su tarea. Las interfaces, conectores, autorizaciones y cambios en datos o sistemas necesitan registros trazables y, para las acciones con consecuencias importantes, aprobación humana.
Reflexión final
En el trabajo, no se trata solo de un texto útil o un buen resumen. Se trata de si un servicio concreto puede tratar determinados datos para una finalidad concreta conforme a los contratos, requisitos de protección de datos y controles de seguridad aplicables.
Por tanto, el mejor hábito es breve y eficaz: antes de pegar o cargar algo, compruebe el contenido, la finalidad, la herramienta y la autorización. Minimice o anonimice los datos localmente cuando sea admisible y apropiado. Si el flujo de datos sigue sin estar claro, deténgase antes de escribir el prompt.
Fuentes y notas
[1] KPMG and the University of Melbourne, Trust, attitudes and use of artificial intelligence: A global study 2025.
[2] Ruben Hassid, «How to Use Your Personal AI at Work», Substack, consultado el 11 de julio de 2026. Enlace
[3] OpenAI, «How your data is used to improve model performance» y «Data Controls FAQ». La documentación describe disposiciones diferentes para las ofertas personales y empresariales, así como controles de datos para los chats temporales. Enlace
[4] Anthropic, «Is my data used for model training?». La documentación distingue los productos de consumo de las ofertas comerciales, como Claude for Work y la API. Enlace
[5] NIST, Artificial Intelligence Risk Management Framework (AI RMF 1.0), 2023.
[6] NIST, Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile, 2024.
[7] ISO/IEC, ISO/IEC 42001:2023 - Artificial intelligence management systems.
[8] European Data Protection Board, Opinion 28/2024 on certain data protection aspects related to the processing of personal data in the context of AI models.
[9] Information Commissioner's Office, What are the accountability and governance implications of AI?
[10] European Commission, AI Literacy - Questions & Answers.
[11] OWASP Foundation, Top 10 for LLMs and GenAI Apps, 2025.
[12] Batool, Zowghi and Bano, AI governance: a systematic literature review, AI and Ethics, 2025.
[13] Birkstedt et al., AI governance: themes, knowledge gaps and future agendas, Internet Research, 2023.
[14] Schneider et al., Governance of Generative Artificial Intelligence for Companies, preprint, 2024.