Uso y seguridad de la IA

La IA en la sombra (shadow AI) es el uso de herramientas de IA en el trabajo sin el conocimiento o la aprobación de los responsables de TI, seguridad o protección de datos. Incluye empleados que usan cuentas personales de chatbot para tareas de trabajo, extensiones de navegador con IA integrada, funciones de IA activadas en software que ya existe, desarrolladores que ejecutan modelos locales o asistentes de programación y agentes de IA conectados a sistemas de la empresa. Suele tener buena intención: la gente quiere trabajar más rápido. Los riesgos son concretos. Datos de la empresa o de clientes van a proveedores con los que no tiene contrato, en condiciones que pueden permitirles guardarlos o entrenar modelos con ellos. Puede haber datos personales tratados sin base jurídica. Los resultados entran en documentos y código sin revisión. Y nadie puede responder a un cliente o auditor que pregunta qué servicios de IA tocaron sus datos. La respuesta no es prohibir, sino visibilidad, una alternativa aprobada y una política clara. Desde el plan Pro, NetSenX muestra qué equipos se conectan a qué servicios de IA y cuántos datos van allí, no lo que se escribió.

Sí, desde el plan Pro. NetSenX señala el tráfico hacia servicios de IA externos y hacia modelos de lenguaje ejecutados localmente, para que el uso de IA no aprobado sea visible antes de convertirse en un problema de protección de datos.

Fíjese en las conexiones salientes hacia servicios de IA: el destino y el nombre del servidor en el handshake TLS identifican el servicio sin descifrar nada. NetSenX señala ese tráfico, y el que va a entornos de modelos de lenguaje ejecutados en local, desde el plan Pro.

Normalmente más de los que alguien ha anotado, y esa diferencia es justo la razón para averiguarlo. Una lista realista tiene cuatro capas: los servicios que paga con cuentas de empresa; las funciones de IA activadas dentro del software que ya usa, como paquetes ofimáticos, CRM, soporte o herramientas de diseño; los servicios a los que el personal accede con cuentas personales en el navegador o en aplicaciones de escritorio; y los modelos que se ejecutan en local en portátiles, servidores de compilación o estaciones con GPU. Empiece por lo que sabe, a partir de contratos, extractos de tarjetas y consolas de administración, y añada después lo que muestra la red. Agrupe los resultados por función de negocio, porque finanzas, ventas y desarrollo suelen usar herramientas distintas para datos distintos, y asigne a cada servicio un estado: aprobado, tolerado para datos no sensibles o a sustituir. La lista es la base de su política de IA, de la formación en alfabetización en IA que pide la Ley de IA y de las respuestas a clientes. Desde el plan Pro, NetSenX muestra qué equipos llegan a qué servicios de IA externos y entornos de modelos locales, cuándo y con cuántos datos; no muestra lo que se escribió.

Se puede medir a nivel de red, por servicio y por equipo, y esa cifra es más útil de lo que parece. El volumen no dice qué eran los datos, pero distingue un uso ligero, como preguntas y respuestas cortas, de uno intensivo, como subir documentos enteros, hojas de cálculo, repositorios de código o audio. Un salto repentino en un equipo, o un flujo constante desde un servidor que no debería hablar con servicios de IA, es motivo para preguntar. Sígalo cada mes, por función de negocio, junto a su lista de servicios aprobados: que crezca el uso de una herramienta aprobada es buena noticia; que crezca el de una no aprobada es un hueco en la política. La consola de administración de su proveedor de IA puede añadir detalle por usuario en las cuentas empresariales. Desde el plan Pro, NetSenX muestra qué equipos llegan a qué servicios de IA, incluidos entornos de modelos locales, y cuántos datos van a cada uno a lo largo del tiempo. Nunca lee el contenido, así que no puede decir si los datos eran confidenciales; ese juicio corresponde a quienes son responsables de ellos.

En parte. Los registros DNS muestran qué equipos consultan los dominios de servicios de IA conocidos, un buen comienzo que no cuesta nada si su resolutor ya registra las consultas: exporte una semana de consultas y crúcelas con una lista de dominios de IA. Se les escapa el DNS cifrado que evita su resolutor, los servicios a los que se llega por otros dominios o redes de distribución de contenidos, las funciones de IA integradas en herramientas que ya usa y cuántos datos se movieron realmente. Además muestran el equipo, no la persona, y una consulta suelta puede venir de un navegador que precarga una página. Tome el DNS como una primera vista barata y confirme con datos de conexión antes de actuar. NetSenX combina desde el plan Pro los destinos con el volumen y la hora de las conexiones, así que ve qué equipos usan qué servicios de IA, incluidos entornos de modelos locales, y con qué intensidad; no ve el contenido de los prompts. Para el contenido, combínelo con los registros de administración de su proveedor de IA.

Sí las conexiones, no el contenido. Una aplicación de chatbot de escritorio, un asistente de IA dentro de un editor de código y una herramienta de línea de comandos que llama a una API de IA tienen que llegar al proveedor por la red, así que destino, momento y volumen se ven igual que con un navegador. Importa porque estas herramientas suelen escapar a los controles basados en el navegador: una política de extensiones o un proxy web no las ven, y los asistentes de IA de los desarrolladores pueden enviar como contexto gran parte de un código fuente. Límites: cuando la herramienta habla con un punto de acceso genérico en la nube o con un proxy corporativo, el proveedor de IA puede quedar oculto detrás; Encrypted Client Hello puede ocultar el nombre del servidor; y los portátiles usados fuera de la oficina solo se ven si el agente funciona en ellos. NetSenX muestra desde el plan Pro qué equipos se conectan a qué servicios de IA externos y a entornos de modelos de lenguaje ejecutados en local, y cuántos datos van a cada uno, sea cual sea la aplicación que abrió la conexión; no ve qué fichero o prompt se envió.

No. El contenido de la sesión va cifrado y NetSenX nunca lo descifra. Muestra que un equipo usó un servicio de IA, cuándo y cuántos datos envió; para el contenido se necesitan los registros de la versión empresarial del servicio o una herramienta DLP.

Porque el contenido viaja dentro de conexiones cifradas hacia servicios que la empresa no controla. Cuando alguien pega un texto en un chatbot desde el navegador, el cortafuegos ve una conexión HTTPS con el proveedor y, como mucho, el nombre del servicio; el prompt va cifrado de extremo a extremo entre el navegador y el proveedor. Las cuentas personales guardan el historial en el proveedor, fuera del alcance de la empresa. Las funciones de IA dentro de aplicaciones aprobadas parecen tráfico normal de esas aplicaciones, y los móviles con datos móviles ni siquiera pasan por la red de la empresa. Ver el contenido exige control en uno de los extremos: una cuenta empresarial cuya consola de administración y registros de auditoría muestren el uso, prevención de pérdida de datos en el navegador o en el equipo, o un proxy de interceptación, cada uno con sus propias cuestiones de privacidad. Lo que puede dar la red es lo siguiente mejor: qué equipos usan qué servicios de IA, cuándo y cuánto. Eso es exactamente lo que muestra NetSenX desde el plan Pro.

No. Forma parte del plan Pro y superiores. El plan Free cubre la detección por comportamiento, como el beaconing, los escaneos y el movimiento lateral, sin límite de tiempo.

Depende de dónde esté la herramienta, y merece la pena pedir la respuesta por escrito a cada proveedor, porque la misma etiqueta cubre cosas muy distintas. Una herramienta en el equipo ve qué aplicaciones de IA y extensiones de navegador están instaladas y a veces qué webs se visitan; una basada en DNS ve las consultas a dominios de IA a través del resolutor que controla; una extensión de navegador ve las páginas y, con los permisos adecuados, lo que se escribe en ellas; un sensor de red ve las conexiones a servicios de IA con su volumen y momento; y las consolas de administración de los proveedores de IA muestran el uso de las cuentas empresariales. Ninguna ve todo por sí sola. Pregunte en concreto: de qué fuente sale la visibilidad, si ve contenido o solo destinos, si cubre aplicaciones de escritorio y modelos locales, cómo trata el DNS cifrado, qué hace en equipos no gestionados y qué datos personales de los empleados recoge. NetSenX pertenece a la categoría de red: desde el plan Pro muestra qué equipos llegan a qué servicios de IA externos y entornos de modelos locales y cuántos datos se mueven, nunca lo que se escribió.

Depende menos del servicio que de la cuenta y de los datos. La conexión va cifrada y los grandes proveedores tienen programas de seguridad maduros, así que los riesgos principales están en otra parte. Una cuenta personal se rige por condiciones de consumo: según el proveedor y los ajustes, las conversaciones pueden guardarse y usarse para mejorar los modelos, y la empresa no tiene vista de administración, ni contrato de encargo del tratamiento, ni forma de borrar lo compartido. Una cuenta empresarial suele cambiar eso, con límites contractuales al entrenamiento, ajustes de conservación, inicio de sesión único, controles de administración y registros de auditoría. Los demás riesgos son humanos: datos confidenciales o personales pegados sin pensar, respuestas seguras pero erróneas y código o texto generado usado sin revisión. Reglas prácticas: herramienta aprobada con cuenta de empresa, una lista corta de datos que nunca entran, autenticación multifactor (MFA) en la cuenta y revisión de los resultados antes de que lleguen a clientes. NetSenX muestra desde el plan Pro qué servicios de IA se usan de verdad y cuántos datos van a ellos.

Trate un servicio de IA como a cualquier otro proveedor que trata sus datos, y configúrelo a conciencia. Elija uno o dos servicios aprobados y use cuentas empresariales con inicio de sesión único y autenticación multifactor, para que quien se va pierda el acceso y los administradores vean el uso. Revise el contrato: si sus datos se usan para entrenar, cuánto tiempo se guardan, dónde se tratan y si hay un contrato de encargo del tratamiento conforme al RGPD. Redacte una política de una página con ejemplos de lo que puede y no puede introducirse y a quién preguntar. Active los controles de administración del proveedor, como los límites de conservación y las restricciones de plugins o conectores. Decida cómo se revisan los resultados antes de llegar a clientes o a código de producción. Forme a la gente en la política y en el deber de alfabetización en IA de la Ley de IA. Después compruebe la realidad: desde el plan Pro, NetSenX muestra qué servicios de IA usan realmente los equipos, incluidos los no aprobados y los modelos locales, y cuántos datos van a cada uno, sin leer el contenido.

Empiece por una política que la gente pueda cumplir: qué herramientas de IA están aprobadas, para qué datos y con qué cuenta de empresa. Después haga que la herramienta aprobada sea fácil de usar, porque la gente esquiva las normas que le bloquean el trabajo, y una cuenta empresarial con un proveedor de IA suele ofrecer condiciones contractuales sobre el uso de los datos, controles de administración y registros que una cuenta personal no tiene. Explique el motivo con ejemplos concretos: listas de clientes, contratos, código fuente, datos salariales y todo lo sujeto a un acuerdo de confidencialidad se quedan fuera de las herramientas no aprobadas. Luego vienen los controles técnicos: prevención de pérdida de datos en los equipos o en el navegador, un proxy web y los ajustes de administración del propio proveedor de IA. Compruebe el resultado cada mes, no una sola vez. NetSenX da visibilidad, no bloqueo: desde el plan Pro muestra qué equipos hablan con qué servicios de IA y cuántos datos van allí, para que vea si la política funciona. No ve lo que se escribió ni lo que se subió.

Bloquear sin más rara vez funciona: la gente se pasa al móvil, a la red de casa o a otras herramientas de IA, y usted pierde de vista el uso, justo lo contrario de lo que busca. Las listas de bloqueo además se quedan atrás, porque cada mes aparecen nuevos servicios de IA y muchos vienen integrados en aplicaciones que ya permite. Un camino más claro tiene tres partes: una política sobre qué herramientas de IA están aprobadas y qué datos pueden introducirse; una herramienta aprobada con cuenta empresarial donde haya demanda real, para que la gente tenga una buena alternativa; y visibilidad de lo que realmente se usa, revisada con regularidad. El bloqueo sigue teniendo sentido para servicios concretos de alto riesgo, para equipos no gestionados en la red de invitados o durante un incidente. NetSenX muestra desde el plan Pro a qué servicios de IA se conectan los equipos de la red, incluidos los modelos que se ejecutan en local, y cuántos datos van a cada uno; ve el destino y el volumen, no lo que se escribió, y no bloquea nada por sí mismo.

Empiece por averiguar qué se usa y por qué, antes de escribir normas. En la mayoría de las empresas, la primera ola de uso de IA viene de personas que resuelven problemas reales: redactar correos, resumir documentos, escribir código o traducir. Prohibir lo empuja fuera de la vista; una herramienta aprobada con pautas claras lo mantiene visible. Después explique los riesgos con el lenguaje del trabajo: un contrato de cliente pegado en un chatbot personal puede vulnerar la cláusula de confidencialidad; un resumen de IA puede omitir justo la frase que importa; el código generado puede traer vulnerabilidades o problemas de licencia. Dé una lista corta de datos que nunca entran en herramientas no aprobadas, enseñe a usar la aprobada y nombre a alguien a quien preguntar. Las formaciones cortas y repetidas funcionan mejor que una sesión larga, y desde febrero de 2025 la Ley de IA exige a las organizaciones que usan IA adoptar medidas para fomentar la alfabetización en IA de su personal. Mida el avance con hechos: desde el plan Pro, NetSenX muestra qué servicios de IA se usan de verdad y cuántos datos van allí.

Compare lo que permite la política con lo que la empresa usa de verdad, a partir de tres fuentes. Primero, las consolas de administración de los servicios de IA aprobados: quién tiene cuenta, cuánto la usa y qué funciones y conectores están activados. Segundo, los datos de identidad y de gastos: inicios de sesión con direcciones de correo de la empresa en servicios que nadie aprobó y suscripciones de IA en tarjetas de empresa. Tercero, la red: qué equipos se conectan a qué servicios de IA, incluidos entornos de modelos locales, y cuántos datos van a cada uno. Un buen informe mensual muestra los servicios aprobados y su uso, los no aprobados que siguen en uso y las transferencias inusualmente grandes, para que la conversación se base en hechos y no en rumores. Céntrese en herramientas y equipos, no en personas, salvo que haya una sospecha concreta, e implique a RR. HH. o a la representación de los trabajadores cuando lo exija la ley de su país. Desde el plan Pro, NetSenX ofrece la vista de red: equipos, servicios de IA y volúmenes a lo largo del tiempo. No lee lo que se escribió ni bloquea nada.

Solo con una cuenta empresarial aprobada, y solo después de comprobar qué contiene la hoja. Las exportaciones financieras suelen llevar más de lo que necesita el análisis: nombres de clientes y condiciones de pago, salarios, márgenes, datos bancarios y resultados no publicados. Con una cuenta personal, esos datos quedan en un proveedor con el que no tiene contrato, en condiciones que pueden permitir guardarlos o entrenar modelos con ellos. Con una cuenta empresarial con contrato de encargo del tratamiento, ajustes de conservación y sin entrenamiento con sus datos, el riesgo es comparable al de otros servicios en la nube que ya usa. Reglas prácticas para finanzas: quite las columnas que la pregunta no necesita, agregue o seudonimice los datos personales, no suba nunca resultados no publicados de una empresa cotizada ni ficheros bajo acuerdo de confidencialidad, y compruebe las cifras de la IA con la fuente antes de que entren en un informe, porque los modelos pueden calcular o copiar mal los números. NetSenX muestra desde el plan Pro qué equipos de finanzas llegan a qué servicios de IA y cuántos datos van allí; no ve el fichero.

No solo con la red, y conviene reconocerlo con honestidad antes de elegir una herramienta. El contenido que se envía a un servicio de IA va cifrado, así que solo un control en uno de los extremos puede verlo: los registros de administración y auditoría de una cuenta empresarial de IA, la prevención de pérdida de datos en el navegador o en el equipo que reconozca patrones de datos de clientes, o un proxy de interceptación. Cada uno necesita una política clara, información al personal y, en muchos países, la participación de la representación de los trabajadores. Lo que la red muestra de forma fiable es el contexto: qué equipos usan qué servicios de IA, con qué frecuencia y cuántos datos envían. Un portátil de ventas que envía cada día varios megabytes a un chatbot no aprobado es motivo para hablar de herramientas y datos, no la prueba de una brecha. A menudo la mejor respuesta es una alternativa autorizada que haga lo mismo con una cuenta empresarial. Desde el plan Pro, NetSenX muestra equipos, servicios de IA y volúmenes; nunca ve el texto pegado.

Puede serlo, según los datos, la cuenta y las condiciones. Según el RGPD, Reglamento (UE) 2016/679, enviar datos personales a un proveedor de IA es un tratamiento que necesita base jurídica, transparencia hacia los interesados y, cuando el proveedor actúa por cuenta de usted, un contrato de encargo del tratamiento. Las transferencias fuera de la UE requieren sus propias garantías. Con una cuenta empresarial con ese contrato y ajustes que impidan entrenar con sus datos, el uso para un fin definido puede ser lícito. Pegar correos de clientes en una cuenta personal con condiciones de consumo es más difícil de justificar y puede suponer una comunicación no autorizada, que el RGPD trata como violación de la seguridad de los datos personales; si es probable que entrañe un riesgo para las personas, el responsable debe notificarla a la autoridad de control en un plazo de 72 horas según el artículo 33. Implique a su delegado de protección de datos, anote qué se compartió y con qué servicio, y corrija la causa con una herramienta aprobada. NetSenX muestra desde el plan Pro qué equipos enviaron datos a qué servicios de IA, no qué datos eran.

Rara vez como primer paso y nunca solo con datos de red. La mayor parte del uso de IA no aprobado viene de personas que intentan hacer su trabajo más rápido, a menudo porque no hay una herramienta aprobada o porque nunca se explicó la política. Despedir por un primer incumplimiento de buena fe puede ser desproporcionado según el derecho laboral de muchos países de la UE, y enseña al resto de la plantilla a esconder el uso en lugar de preguntar. Una secuencia más sensata: asegurarse de que la política era clara, se comunicó y era razonable; ofrecer una alternativa aprobada; tratar un primer incumplimiento con una conversación y una advertencia por escrito; y reservar las medidas disciplinarias para incumplimientos deliberados o repetidos, o para daños graves como revelar datos confidenciales de un cliente. Decida con RR. HH. y asesoría jurídica, e implique a la representación de los trabajadores cuando lo exija la ley de su país. Un sensor de red no puede establecer quién hizo qué: NetSenX muestra qué equipo se conectó a qué servicio de IA y cuántos datos se movieron, un punto de partida para preguntar, no una prueba de la intención de una persona.

Sobre todo que los datos de la empresa salgan en condiciones que nadie aceptó y que nadie pueda dar cuenta de ello después. La IA propia incluye suscripciones personales a chatbots, apps de IA en móviles privados, extensiones de navegador, grabadoras de reuniones con IA y modelos en hardware personal. El riesgo para los datos: documentos, datos de clientes o grabaciones van a proveedores con condiciones de consumo, quizá fuera de la UE, sin contrato de encargo del tratamiento, y se quedan en cuentas personales cuando el empleado se va. El riesgo de calidad: trabajos basados en resultados que nadie comprobó. El riesgo de cumplimiento: no puede responder a un cliente, un auditor o un interesado que pregunte adónde fueron sus datos. Las grabadoras de reuniones con IA merecen especial atención, porque captan la voz y las palabras de otras personas, a menudo sin el consentimiento de todos. La respuesta práctica es ofrecer una buena herramienta aprobada, decir con claridad qué herramientas personales pueden usarse y para qué, y exigir que se anuncie la grabación de reuniones. Desde el plan Pro, NetSenX muestra a qué servicios de IA llegan los equipos de la empresa; los móviles personales con datos móviles quedan fuera de cualquier vista de red.

A menudo más que los propios chatbots, por los permisos que piden. Para resumir páginas, reescribir correos o rellenar formularios, una extensión de IA suele necesitar leer y modificar todo en cada web que visita, incluidos el correo web, el CRM, la banca en línea y las aplicaciones internas. Después envía el contenido de las páginas a sus propios servidores o a un proveedor de IA. Algunas extensiones están bien gestionadas; otras son pequeños proyectos que cambian de dueño, se venden o reciben una actualización con rastreo o código malicioso, y el navegador la instala sin avisar. Pasos prácticos: permita solo extensiones de una lista gestionada mediante políticas del navegador, revise los permisos y el editor de cada una, prefiera las funciones de IA de sus herramientas aprobadas a las extensiones y elimine las que nadie pueda justificar. Un sensor de red ve las conexiones de una extensión con sus servidores como cualquier otro tráfico, pero no puede saber qué extensión las abrió; el inventario corresponde a la gestión del navegador o de los equipos. Desde el plan Pro, NetSenX muestra qué equipos llegan a qué servicios de IA y cuántos datos van allí.

Si su organización usa sistemas de IA en su trabajo, el artículo 4 del Reglamento le obliga a adoptar medidas para fomentar la alfabetización en IA de su personal, y esa obligación se aplica desde el 2 de febrero de 2025; desde julio de 2026, el texto modificado aclara que no hay que garantizar un nivel concreto en cada persona. Saber qué servicios de IA se usan de verdad es un primer paso práctico; su asesoría jurídica le dirá qué más le afecta.

En parte, sí. El Reglamento (UE) 2024/1689 impone obligaciones a los responsables del despliegue, es decir, a las organizaciones que usan sistemas de IA en su actividad, y no solo a los proveedores que los crean. Desde el 2 de febrero de 2025, el artículo 4 exige a proveedores y responsables del despliegue adoptar medidas sobre la alfabetización en IA del personal que trata con sistemas de IA; en la versión modificada en julio de 2026 por el Reglamento (UE) 2026/1744, se trata de fomentar esa alfabetización, sin garantizar un nivel concreto en cada persona. Las prohibiciones del artículo 5 también se aplican desde el 2 de febrero de 2025. Otras obligaciones dependen de la categoría de riesgo del sistema y se aplican en fechas posteriores: quien despliega un sistema de alto riesgo, por ejemplo en selección de personal o decisiones de crédito, tiene obligaciones de supervisión humana, seguimiento y registros, y algunos usos conllevan deberes de transparencia hacia las personas afectadas. Usar un chatbot generalista para redactar textos está en el extremo ligero. Un buen comienzo es inventariar los sistemas de IA que realmente usa y para qué, y después ajustar la formación a esa lista. Compruebe los detalles con asesoría jurídica, porque todavía se están publicando directrices.

Supone que la empresa debe adoptar medidas que fomenten la alfabetización en IA del personal que trata con sistemas de IA, y suele ser RR. HH. quien lo organiza. El artículo 4 del Reglamento (UE) 2024/1689 se aplica desde el 2 de febrero de 2025 tanto a proveedores como a responsables del despliegue, así que alcanza a empresas corrientes que usan herramientas de IA; en la versión modificada en julio de 2026 por el Reglamento (UE) 2026/1744, aclara que la empresa no tiene que garantizar un nivel concreto de alfabetización en IA en cada persona. Unas buenas medidas siguen teniendo en cuenta los conocimientos técnicos, la experiencia, la educación y la formación de las personas, y el contexto en que se usan los sistemas de IA. El artículo 4 no prescribe un certificado, un número fijo de horas ni un curso único. Pasos prácticos: haga una lista de los sistemas de IA que se usan de verdad y de quién los usa; defina qué debe saber cada grupo, desde riesgos básicos y la política de la empresa para todos hasta formación más profunda para quien configura la IA o se apoya en ella para decidir; lleve un registro sencillo de quién se formó en qué y cuándo; y repita cuando cambien las herramientas. NetSenX puede ayudar en el primer paso: desde el plan Pro muestra qué servicios de IA usan realmente los equipos de la empresa.

Las que su gente usa de verdad, que rara vez son las de la política. Empiece por un inventario: servicios aprobados en cuentas de empresa, funciones de IA dentro del software que ya paga, servicios que el personal usa con cuentas personales y modelos locales en equipos de desarrollo o ingeniería. Después ajuste la formación al uso. Todo el mundo necesita lo básico: cuáles son las herramientas aprobadas, qué datos nunca entran en ninguna herramienta de IA, por qué las respuestas pueden ser erróneas y cómo informar de un problema. Quienes usan IA con datos de clientes o personales, en finanzas, RR. HH. o ventas, necesitan las normas de protección de datos y confidencialidad que les afectan. Los desarrolladores necesitan un uso seguro de asistentes de programación y agentes, incluido a qué tienen acceso esas herramientas. Los directivos que se apoyan en resultados de IA para decidir deben entender sus límites. Formar en herramientas que nadie usa es perder tiempo; dejar fuera las de uso diario deja intacto el riesgo real. Desde el plan Pro, NetSenX muestra a qué servicios de IA externos y entornos de modelos locales llegan los equipos de la empresa, para que la lista de formación coincida con la realidad.

Por regla general, no. El artículo 5 de la Ley de IA, Reglamento (UE) 2024/1689, prohíbe introducir en el mercado, poner en servicio o utilizar sistemas de IA para inferir las emociones de una persona física en el lugar de trabajo y en centros educativos, salvo cuando el sistema esté destinado a fines médicos o de seguridad. La prohibición se aplica desde el 2 de febrero de 2025. Alcanza a herramientas que leen emociones o intenciones a partir de la cara, la voz, la forma de teclear u otras señales biométricas, por ejemplo en software de centros de llamadas, complementos de videoconferencia o control de productividad, y las multas por prácticas prohibidas son las más altas de la norma. El derecho laboral y la protección de datos añaden sus propios límites a la vigilancia del personal. Antes de comprar una herramienta que dice medir el compromiso, el estrés o el ánimo de los empleados, pida al proveedor por escrito qué datos usa y cómo encaja con el artículo 5, e implique a su asesoría jurídica y a su delegado de protección de datos. NetSenX no hace esto: supervisa equipos y conexiones de red, nunca personas, y no evalúa a individuos.

Con una respuesta concreta y comprobable, no con una promesa tranquilizadora. Los clientes y sus departamentos de compras preguntan cada vez más qué servicios de IA tocan sus datos, en qué condiciones y con qué controles. Una buena respuesta nombra los servicios de IA aprobados y cómo están contratados, por ejemplo cuentas empresariales sin entrenamiento con sus entradas, con contrato de encargo del tratamiento y ubicaciones de tratamiento indicadas; dice qué datos del cliente pueden entrar y cuáles no; describe los controles, como la política de IA, la formación del personal, las restricciones de acceso y la revisión de resultados; y explica cómo comprueba que la práctica coincide con la política. Si hoy la respuesta honesta es que no lo sabe, diga qué está haciendo para averiguarlo y para cuándo, en lugar de prometer algo que no puede demostrar. Mantenga la respuesta coherente con sus contratos y su registro de actividades de tratamiento. Desde el plan Pro, NetSenX muestra a qué servicios de IA llegan de verdad los equipos de su empresa y cuántos datos van a cada uno, para que la respuesta al cliente se apoye en su propio tráfico y no en suposiciones; no muestra de qué cliente eran los datos.

A menudo sí, al menos como compromiso en el que el cliente pueda confiar, pero el contrato debe ser más corto que la política. Los clientes añaden cada vez más cláusulas sobre IA: no usar sus datos para entrenar modelos, no tratarlos con servicios de IA fuera de los subencargados o regiones acordados, informar cuando los entregables se hagan con ayuda de IA y notificar si sus datos quedaron expuestos a través de una herramienta de IA. En lugar de adjuntar toda su política interna, que cambia a menudo, comprométase en el contrato o en el contrato de encargo del tratamiento con unos pocos principios estables, incluya como subencargados los servicios de IA que traten datos del cliente cuando sea así y remita a la política que usted mantiene. Asegúrese de poder cumplir cada promesa en la práctica: una cláusula que diga que nunca entran datos de clientes en herramientas de IA no vale nada si el personal usa cuentas personales de chatbot y usted no lo ve. Acuerde qué cuenta como trabajo asistido por IA, porque la mayoría del software de oficina ya tiene funciones de IA. Haga revisar la redacción por asesoría jurídica. Desde el plan Pro, NetSenX muestra a qué servicios de IA llegan realmente sus equipos, una comprobación útil antes de firmar una cláusula así.

Busque los servicios que exponen los entornos de modelos locales y el tráfico que los rodea. Las herramientas que ejecutan modelos de lenguaje en local suelen abrir una API HTTP en un puerto predeterminado conocido, ofrecen una interfaz web y, al configurarse, descargan grandes ficheros de modelos desde repositorios públicos. Ayudan tres comprobaciones: un escaneo autorizado de los rangos internos en busca de los puertos predeterminados de los entornos habituales y de interfaces web inesperadas; ver qué máquinas descargaron ficheros de varios gigabytes desde repositorios de modelos; y una lista de equipos con GPU potentes, que TI suele conocer. Después pregunte a los responsables para qué sirve cada servidor, quién puede acceder y qué datos entran en él. Muchos son experimentos inofensivos; algunos quedan abiertos a toda la red sin autenticación. NetSenX muestra desde el plan Pro el tráfico hacia entornos de modelos de lenguaje ejecutados en local: qué equipo ejecuta o llama a uno y cuántos datos se mueven, junto a los servicios de IA externos. No ve los prompts ni las respuestas del modelo.

Puede serlo, sobre todo por errores de configuración corrientes y no por algo exótico. Mantener los datos en hardware propio evita enviarlos a un proveedor externo, y eso es una ventaja real. Los riesgos son los de cualquier servidor nuevo que nadie planificó: la API o la interfaz web suelen escuchar en todas las interfaces sin autenticación, así que cualquiera en la red puede usar el modelo, leer el historial de conversaciones o subir ficheros; el servidor ejecuta software sin parchear que cambia rápido; los ficheros de modelos descargados de repositorios públicos pueden contener código malicioso si usan formatos inseguros; y los documentos cargados para búsqueda pueden ser legibles por cualquiera que llegue al servidor. Trátelo como cualquier servicio interno: un responsable designado, autenticación, escucha limitada a localhost o a un segmento restringido, actualizaciones, formatos de modelo seguros de fuentes fiables y una decisión sobre qué datos pueden entrar. Desde el plan Pro, NetSenX muestra qué equipos ejecutan o llaman a entornos de modelos de lenguaje locales y cuántos datos se mueven, y sus detecciones básicas señalan en todos los planes escaneos o movimiento lateral desde ese equipo.

Es el riesgo de que un modelo, un conjunto de datos o una biblioteca de IA que descarga o compra esté comprometido, mal descrito o simplemente no sea lo que cree. Los repositorios públicos de modelos alojan cientos de miles de modelos subidos por cualquiera. Algunos formatos de fichero de modelo pueden ejecutar código al cargarse, así que un modelo malicioso puede comprometer el equipo que lo abre; existen formatos más seguros y conviene preferirlos. Un modelo puede ajustarse para comportarse con normalidad salvo ante un disparador oculto, o entrenarse con datos envenenados. Los nombres pueden copiarse para parecer el modelo de un editor conocido. Y las bibliotecas y plugins alrededor de los modelos, como entornos de ejecución, conectores y frameworks de agentes, cambian deprisa y tienen vulnerabilidades de software corrientes. Pasos prácticos: tome modelos solo de editores que pueda verificar, compruebe firmas o hashes cuando se publiquen, use formatos de fichero seguros, ejecute primero los modelos nuevos en un entorno aislado, mantenga un inventario de modelos y versiones en uso y parchee el software que los rodea como cualquier otro. Un sensor de red ve las descargas grandes de modelos y qué equipos ejecutan entornos de modelos; no puede inspeccionar los pesos de un modelo.

Puede serlo, igual que el código copiado de internet, solo que más rápido y en mayor cantidad. Los asistentes de programación producen código verosímil que suele funcionar, pero que puede contener patrones de vulnerabilidad conocidos como fallos de inyección, criptografía débil o falta de validación de entradas; llamar a paquetes que no existen y que luego los atacantes registran con ese nombre y contenido malicioso; reproducir código con una licencia que su producto no puede aceptar; e incrustar secretos de ejemplos. Las propias herramientas envían además código fuente al proveedor como contexto, así que la elección de servicio y cuenta importa para la confidencialidad. Trate lo que produce la IA como la pull request de un compañero junior: la misma revisión de código, pruebas de seguridad automatizadas, análisis de dependencias y licencias y detección de secretos en el pipeline, y la responsabilidad sigue siendo del desarrollador. Decida qué repositorios pueden compartirse con qué asistente. Desde el plan Pro, NetSenX muestra qué equipos de desarrollo y servidores de compilación envían datos a qué servicios de IA y cuántos; no puede juzgar la calidad del código.

La inyección de prompts es un ataque en el que un texto que lee un sistema de IA está escrito para que ignore sus instrucciones y haga otra cosa. La inyección directa viene del usuario que la escribe. La indirecta es la más seria para las empresas: la instrucción se esconde en contenido que la IA procesa por cuenta de alguien, como una página web, un correo, un documento compartido o una incidencia de soporte, y el modelo la sigue como si viniera de su operador. Si la IA solo puede responder en una ventana de chat, el daño se limita a una respuesta errónea o embarazosa. Si puede leer un buzón, llamar a herramientas, consultar una base de datos o navegar, una instrucción inyectada puede hacer que filtre datos o ejecute acciones. Hoy no hay una solución completa, porque los modelos no separan de forma fiable instrucciones y datos. Lo que ayuda: dar a las herramientas de IA los mínimos permisos posibles, exigir aprobación humana para acciones con consecuencias, mantener los sistemas sensibles fuera del alcance de agentes que leen contenido no fiable y registrar lo que hizo la IA. OWASP sitúa la inyección de prompts en primer lugar entre los riesgos de las aplicaciones basadas en grandes modelos de lenguaje (LLM).

Es una lista de los principales riesgos de seguridad de las aplicaciones basadas en grandes modelos de lenguaje (LLM), publicada por el Open Worldwide Application Security Project (OWASP), la comunidad detrás del conocido Top 10 de aplicaciones web. La edición de 2025 recoge la inyección de prompts, la divulgación de información sensible, los riesgos de la cadena de suministro, el envenenamiento de datos y modelos, el manejo inadecuado de las salidas, la agencia excesiva, la filtración del prompt de sistema, las debilidades de bases de datos vectoriales y embeddings, la desinformación y el consumo ilimitado de recursos. Para una empresa que solo usa herramientas de IA, importan sobre todo tres puntos: la divulgación de información sensible, que es el problema de la IA en la sombra; la agencia excesiva, es decir, agentes de IA con más permisos de los que necesitan; y la inyección de prompts, que convierte cualquier documento o web que lee un agente en un posible ataque. Para una empresa que integra IA en su propio producto, la lista completa es una buena lista de control para revisiones de diseño y pruebas, y un vocabulario común para los cuestionarios de seguridad de los clientes. Es una guía, no una norma ni una certificación.

Diseñe para que el modelo solo vea lo que necesita la tarea, y dé por hecho que todo lo que ve puede volver a salir. En concreto: elija un despliegue con condiciones contractuales adecuadas a sus datos, como una API empresarial sin entrenamiento con las entradas, con plazo de conservación definido y tratamiento en la UE cuando haga falta, o un modelo que aloje usted mismo; minimice y seudonimice lo que entra en los prompts; en los sistemas de recuperación de documentos, aplique los permisos del propio usuario sobre los documentos que el modelo puede recuperar, para que no resuma ficheros que el usuario no puede abrir; mantenga secretos, claves y credenciales de sistema fuera de los prompts y del contexto; filtre las salidas en busca de datos personales y secretos antes de que lleguen a usuarios o registros; limite las herramientas que el modelo puede llamar y exija aprobación para las acciones; y registre prompts y respuestas de forma protegida para investigaciones, con una conservación ajustada. Pruebe frente a inyección de prompts e intentos de extracción de datos antes del lanzamiento y tras cada cambio. Desde el plan Pro, NetSenX muestra qué servidores envían datos a qué servicios de IA externos y cuántos, lo que ayuda a confirmar que el tráfico de producción solo va adonde dice el diseño.

El Model Context Protocol (MCP) es un protocolo abierto, presentado por Anthropic en noviembre de 2024 y adoptado ampliamente desde entonces, que permite a asistentes y agentes de IA conectarse de forma estándar con herramientas y fuentes de datos. Un servidor MCP expone capacidades, como leer ficheros, consultar una base de datos, buscar en un sistema de incidencias o enviar mensajes, y un cliente de IA las llama cuando una tarea lo requiere. Eso hace la IA mucho más útil, y también convierte cada servidor MCP en una puerta: todo lo que él puede alcanzar, lo alcanza la IA, con los permisos de la cuenta que hay detrás. Las preguntas de seguridad salen solas. ¿Quién instaló el servidor y desde dónde? ¿Qué credenciales guarda y qué alcance tienen? ¿Funciona en local en un portátil o como servicio remoto? ¿Exige aprobación antes de actuar? ¿Queda registrado? Trate los servidores MCP como software con acceso privilegiado: apruébelos, limite al máximo sus tokens, manténgalos actualizados y prefiera servidores de editores verificados. Un sensor de red ve los servidores MCP remotos como conexiones a sus equipos; los locales en un portátil quedan fuera de su vista.

Un servidor MCP en la sombra es un servidor Model Context Protocol que alguien conectó a un asistente de IA sin que lo sepa TI, normalmente para ahorrar tiempo: un conector al buzón de la empresa, a una carpeta compartida, a un repositorio de código, a una base de datos o a una herramienta de incidencias, instalado desde un catálogo público o escrito en una tarde. El riesgo es que crea en silencio un nuevo camino de acceso. A menudo guarda un token de acceso personal o una clave de API con permisos amplios, en un fichero de configuración de un portátil; puede venir de un autor desconocido y actualizarse solo; permite a la IA actuar en sistemas de la empresa con los permisos de esa persona; y todo lo que lee la IA, incluida una instrucción maliciosa escondida en un documento o una web, puede dirigir lo que hace a través de ese conector. Nadie lo revisa ni lo registra, y sobrevive a la salida del empleado si no se revoca el token. Pasos prácticos: publique una lista de servidores MCP aprobados, limite al máximo los tokens y rótelos, revise en los registros del proveedor de identidad las nuevas autorizaciones OAuth a clientes de IA e incluya los conectores en el proceso de baja. Un sensor de red ve las conexiones de un portátil con servicios remotos, no la configuración MCP que hay en él.

Busque donde los agentes obtienen su poder: identidades, conectores y plataformas de automatización, y confírmelo después con el tráfico de red. Un agente de IA es software que usa un modelo de lenguaje para decidir pasos y ejecutarlos, como leer incidencias, consultar sistemas, escribir código o enviar correos, normalmente mediante claves de API, cuentas de servicio o autorizaciones OAuth. Por eso las mejores primeras fuentes son su proveedor de identidad y las consolas de administración de sus servicios SaaS: nuevas aplicaciones OAuth con permisos amplios, cuentas de servicio o tokens personales creados hace poco y funciones de IA con conectores activados. Después revise las plataformas de automatización y low-code, los pipelines de CI y los equipos de desarrollo en busca de frameworks de agentes y servidores MCP, y pregunte directamente a los equipos, porque muchos agentes son pilotos que nadie ha registrado. La red añade la vista de comportamiento: qué servidores o puestos llaman a API de IA con regularidad, de noche o a ráfagas, y cuáles llegan además a sistemas internos. Desde el plan Pro, NetSenX muestra qué equipos hablan con qué servicios de IA externos y entornos de modelos locales y cuántos datos se mueven. No identifica un agente por su nombre, y las señales de comportamiento propias de agentes todavía no son alertas.

Sí, y normalmente con controles más estrictos que a una persona con los mismos permisos. Un agente actúa a velocidad de máquina, no se cansa ni sospecha, puede dirigirlo el texto que lee y a menudo funciona con un token que nunca caduca. Dé a cada agente su propia identidad en lugar de la cuenta de una persona, conceda solo los permisos que necesita la tarea, prefiera el acceso de solo lectura, separe entornos para que un agente de pruebas no toque producción, exija aprobación humana para pagos, borrados, mensajes externos y cambios de permisos, fije caducidad y rotación de sus credenciales y registre cada acción en un lugar que no pueda alterar. Revise los agentes en las mismas revisiones de accesos que las cuentas de servicio e inclúyalos en el proceso de baja. El coste de no hacerlo es concreto: el informe Cost of a Data Breach 2025 de IBM concluyó que el 13 % de las organizaciones notificó brechas en modelos o aplicaciones de IA, y el 97 % de ellas reconoció carecer de controles de acceso adecuados para la IA. En la red, NetSenX detecta en todos los planes el comportamiento de una identidad mal usada, como el movimiento lateral y las subidas inusuales, desde el equipo en el que funciona el agente.

Sí, y sin que nadie lo pretenda. A un agente con acceso a un CRM, a un buzón o a una unidad compartida se le puede pedir, o engañar con una instrucción oculta en un documento, un correo o una web que lea, que resuma, reenvíe o suba datos mucho más allá de lo que necesita su tarea. Vías habituales: un agente que responde mensajes externos e incluye datos internos en la respuesta, un agente que puede enviar correos o publicar en servicios externos, un agente de programación que sube a un repositorio público código con secretos incrustados y un agente cuyos registros o memoria guardan datos de clientes donde nadie espera. La solución es el alcance: solo los datos que necesita la tarea, ningún canal de salida si no hace falta, aprobación humana antes de que algo salga de la empresa y separación entre agentes que leen contenido no fiable y los que tienen accesos sensibles. Pruebe esos caminos antes de la puesta en marcha. En todos los planes, NetSenX detecta un volumen de datos salientes inusual desde un equipo, sea cual sea el proceso que lo cause, y desde el plan Pro muestra con qué servicios de IA habla el equipo; no ve lo que envió el agente.

En parte hoy, y NetSenX dice claramente qué parte. Lo que funciona: desde el plan Pro, el tráfico de un equipo hacia servicios de IA externos y hacia entornos de modelos de lenguaje ejecutados en local, con momento y volumen; y en todos los planes, los comportamientos que un agente mal usado compartiría con cualquier equipo comprometido, como llegar a muchos sistemas internos que nunca usó, escanear, contactar con regularidad con un servidor desconocido o enviar un volumen de datos inusual. Lo que no está activo: las señales dirigidas específicamente a agentes, como acciones a ritmo de máquina justo después de una llamada a un modelo de lenguaje, o una primera conexión a un destino nuevo que sigue a una respuesta del modelo. NetSenX las mide en modo sombra, sin generar alertas, hasta que sean lo bastante fiables para ser útiles; no deben presentarse ni usarse como detecciones. Los controles más fuertes están en otra parte: permisos estrechos, aprobación humana de las acciones con consecuencias y los registros de acciones del propio agente. Un sensor de red tampoco ve nunca qué instrucción hizo actuar al agente.

Sobre todo para hacer ataques conocidos más rápido, más barato y con mejor redacción, no para inventar otros nuevos. Los correos de phishing ya no se delatan por una gramática torpe y pueden adaptarse a su empresa en minutos con información pública. La clonación de voz y los vídeos deepfake hacen más convincentes las llamadas falsas de un directivo o un proveedor. Los atacantes usan IA para escribir y variar scripts, estudiar objetivos y ordenar deprisa los datos robados. Eso cambia la defensa de dos maneras. Los controles que se basaban en detectar una mala redacción o un tono extraño pierden valor, así que los procesos no deben depender de reconocer una falsificación: confirme los cambios de datos de pago por un canal conocido, use autenticación multifactor resistente al phishing y limite lo que puede alcanzar una sola cuenta robada. Y los pasos que siguen al primer punto de apoyo se ven igual en la red, quien o lo que sea que haya escrito las herramientas: un equipo que contacta con un servidor desconocido, escaneos, movimiento lateral y datos que salen. NetSenX detecta esos comportamientos en todos los planes, incluido Free, sin necesidad de reconocer el malware ni el mensaje con el que empezó todo.

Sí, y la defensa es un proceso, no una tecnología. Con unos minutos de audio o vídeo públicos, un atacante puede imitar la voz y la cara de un directivo o un proveedor lo bastante bien como para pasar por teléfono o videollamada, sobre todo con prisas. A principios de 2024, la policía de Hong Kong describió un caso en el que un empleado de una multinacional transfirió grandes sumas tras una videoconferencia en la que los demás participantes, incluido un alto directivo, eran deepfakes. Protección: una norma de que ningún pago, cambio de cuenta bancaria ni transferencia urgente se aprueba solo por una llamada o un mensaje; confirmación por otro canal ya conocido, como devolver la llamada al número que consta en sus registros, nunca al que figura en la solicitud; dos personas para aprobar pagos por encima de un umbral; una palabra clave para las urgencias reales, si lo desea; y un personal que sabe que tendrá respaldo si frena un pago. Ningún sensor de red distingue una voz real de una falsa. NetSenX no es la respuesta aquí: no analiza llamadas ni vídeos y no ve las órdenes de pago.