La fiebre por la IA en pymes abre una brecha nueva: más productividad, más fraude y mucha seguridad improvisada

La IA ha entrado en la pyme española como suelen entrar las tecnologías que prometen ahorrar tiempo: por la puerta de atrás y sin preguntar demasiado a seguridad. Primero fue el equipo comercial redactando correos con copilots. Luego atención al cliente automatizando respuestas. Después recursos humanos filtrando currículos. Y, cuando nadie había terminado de revisar qué datos estaban saliendo, ya había un empleado subiendo contratos, ofertas, extractos o código a una herramienta gratuita con sede jurídica bastante difusa.

Eso es lo que vuelve relevante la advertencia lanzada por Check Point con motivo del Día de las Microempresas y las Pequeñas y Medianas Empresas del 27 de junio. La parte interesante no es la efeméride ni el eslogan oficial de este año. La parte importante es otra: la adopción acelerada de IA en pequeñas y medianas empresas está creando una nueva superficie de ataque justo en el segmento que menos músculo tiene para gobernarla. Más automatización, sí. Más exposición también. Y bastante.

La cuestión no es si la IA introduce riesgo. Eso ya lo hace cualquier software conectado. La cuestión es qué tipo de riesgo introduce en una pyme, cómo se mezcla con obligaciones legales ya vigentes y por qué muchas empresas están abordándolo como si fuera solo una herramienta ofimática algo más lista. No lo es. Es un nuevo punto de entrada para fuga de datos, fraude impulsado por ingeniería social, dependencia opaca de terceros y decisiones automatizadas mal supervisadas. En otras palabras: productividad con letra pequeña.

La parte regulatoria que muchas pymes estan pisando sin mirar: no todo es AI Act, y casi nada empieza ahi

La tentacion habitual es pensar que el problema juridico de la IA empieza y termina en el AI Act. Error bastante caro. Para una pyme que usa asistentes generativos, motores de scoring, chatbots o herramientas de transcripcion, el primer mapa util no es “que dice la ley de IA”, sino “que obligaciones ya activas se disparan cuando meto datos, automatizo decisiones o dependo de un proveedor opaco”. Y ahi el terreno se vuelve menos glamuroso y mas exigente.

Si la herramienta de IA trata datos personales, el punto de partida sigue siendo GDPR art. 5: licitud, minimizacion, limitacion de la finalidad y exactitud. Traducido a operativa real: no puedes volcar CV, contratos, historiales de clientes o tickets con datos identificables en un modelo externo y fingir que eso es solo “usar software”. Si ademas hay un proveedor que trata esos datos por cuenta de la empresa, entra GDPR art. 28, que obliga a formalizar un contrato de encargado con instrucciones documentadas, garantias suficientes y condiciones sobre subencargados. El detalle practico que muchas pymes descubren tarde: si la herramienta gratuita o freemium no te da DPA, ubicacion clara del tratamiento, retencion definida ni control sobre uso para entrenamiento, no tienes un problema de procurement; tienes un problema de base legal y de gobernanza del tratamiento.

El segundo choque llega con GDPR art. 32, que exige medidas tecnicas y organizativas apropiadas al riesgo. Aqui la IA rompe la comodidad del “ya tenemos antivirus y MFA”. Si el riesgo especifico es exfiltracion de datos a prompts, generacion de respuestas falsas enviadas a clientes, o acceso de un proveedor a informacion sensible, las medidas tambien deben ser especificas: filtrado de datos antes del prompt, controles DLP, segregacion de cuentas, logging y evaluacion del proveedor. Cuando el uso puede implicar alto riesgo para derechos y libertades, por ejemplo cribado automatizado de candidatos o perfilado comercial intenso, GDPR art. 35 obliga a una evaluacion de impacto. No es un ritual burocratico. Es el documento que te obliga a contestar por escrito a una pregunta incomoda: para que demonios necesitas usar esta IA con esos datos concretos.

Si la pyme es financiera o presta servicios tecnologicos a una entidad financiera, el mapa cambia de escala. DORA art. 5 exige un marco interno de gestion del riesgo TIC con roles y responsabilidades claros a nivel de organo de direccion. DORA art. 11 pide capacidades de deteccion de actividades anomalas, incidencias y problemas de rendimiento, algo muy relevante cuando el riesgo no viene de malware clasico sino de uso descontrolado de copilots o integraciones API. Y DORA art. 28, sobre gestion del riesgo de terceros TIC, corta de raiz una fantasia muy extendida: que contratar IA como SaaS elimina responsabilidad. No. Obliga a mantener un registro de acuerdos contractuales, evaluar dependencias y vigilar riesgos de concentracion. Si tu banco, aseguradora o fintech apoya un proceso critico sobre un unico proveedor de IA con modelo, hosting y soporte en la misma cadena, ya no tienes solo eficiencia. Tienes riesgo de dependencia estructural.

NIS2 tampoco espera a que el AI Act madure. NIS2 art. 21 obliga a entidades esenciales e importantes a adoptar medidas tecnicas, operativas y organizativas para gestionar riesgos, incluyendo seguridad en la cadena de suministro, gestion de incidentes, continuidad, higiene basica y formacion. El encaje con IA es directo: un chatbot conectado al CRM, una herramienta de resumen de incidentes o un motor de automatizacion documental introduce un nuevo eslabon en esa cadena de suministro digital. Si el proveedor no aclara donde procesa, quien subcontrata o que controles de seguridad aplica, la entidad regulada no puede alegar ignorancia elegante. NIS2 art. 23 ademas fija la notificacion de incidentes significativos con alerta temprana en 24 horas, notificacion en 72 horas e informe final en un mes. Eso obliga a saber distinguir entre “error de uso interno” y “incidente con impacto notificable” cuando un empleado sube a una IA datos de clientes que luego quedan expuestos o reutilizados indebidamente.

El AI Act entra, claro, pero con mas matices de los que suele admitir el marketing. AI Act art. 6 clasifica como alto riesgo determinados sistemas por su uso en productos regulados o en los supuestos del anexo III. Uno de los ejemplos mas delicados para pymes es empleo y gestion de trabajadores: si una empresa usa IA para filtrar candidatos o tomar decisiones que afectan a la relacion laboral, no esta jugando con un simple asistente de RR. HH. Si el sistema encaja en alto riesgo, se activan obligaciones densas para proveedores y, en ciertos casos, para deployers: supervision humana, calidad de datos, documentacion, registro de logs y gestion del riesgo. Y aunque el sistema no sea de alto riesgo, AI Act art. 50 impone obligaciones de transparencia para ciertos sistemas, como informar cuando una persona interactua con una IA en determinados contextos o cuando se genera contenido sintetico. El truco aqui es que muchas pymes ya estan usando chatbots “como si fueran formularios”, sin revisar si el usuario sabe realmente que esta hablando con una maquina ni que se hace con ese intercambio.

Hay una capa adicional que casi nadie mete en la conversacion y deberia: el producto y su seguridad por diseno. El Cyber Resilience Act art. 13 impone a los fabricantes de productos con elementos digitales requisitos esenciales de ciberseguridad, incluyendo gestion de vulnerabilidades y seguridad por defecto. Si una pyme compra software o dispositivos con funciones de IA integradas, el CRA no la convierte automaticamente en obligada principal, pero si cambia el liston de diligencia esperable al seleccionar productos. Dicho sin adornos: sera cada vez menos defendible comprar tecnologia “lista” pero ciega, sin trazabilidad de vulnerabilidades, soporte o politica clara de actualizaciones.

Para poner orden, ISO 27001 anexo A sigue siendo mas util que muchas politicas de IA escritas a toda prisa. Los controles sobre gestion de proveedores, clasificacion de la informacion, control de acceso, registro y monitorizacion, y prevencion de fuga de datos sirven para bajar la discusion del PowerPoint al sistema. NIST CSF 2.0 GV.RM tambien ayuda porque obliga a gobernar riesgo, no a enumerarlo. Si una pyme no sabe que procesos usan IA, que datos entran, que tercero los toca y que decision de negocio depende de esa salida, no tiene una estrategia; tiene fe. Y la fe, en compliance, rara vez impresiona al regulador.

No todas las pymes se juegan lo mismo: banca, seguros, fintech e infraestructura critica tienen dolores distintos

Hablar de “la pyme” como si fuera una categoria uniforme sirve para un titular, pero poco mas. Una correduria de seguros, una fintech de pagos, un proveedor TIC de una entidad bancaria y un operador pequeno en una cadena de infraestructura critica pueden usar el mismo asistente generativo y asumir riesgos radicalmente distintos. La diferencia no es filosofica. Es regulatoria, contractual y operativa.

En banca, incluso cuando la pyme no es una entidad de credito sino un proveedor especializado, la tolerancia al error es baja porque el dato y la continuidad valen mucho. Si una herramienta de IA entra en procesos de atencion al cliente, soporte documental, onboarding o analisis interno, el impacto no se limita a una fuga de informacion comercial. Puede afectar secreto bancario, integridad de instrucciones, autenticacion o trazabilidad. DORA art. 17, sobre clasificacion y tratamiento de incidentes relacionados con las TIC, obliga a las entidades financieras a definir criterios y procedimientos claros. Si una pyme proveedora participa en ese flujo y no conserva logs suficientes o no puede reconstruir que datos pasaron por el sistema, se convierte en el eslabon que bloquea la evaluacion del incidente. Y en cadena eso se paga: con auditorias mas duras, anexos contractuales mas invasivos o, sencillamente, con salida del panel de proveedores.

En seguros, el problema cambia de color. El uso de IA en triaje de siniestros, atencion automatizada o deteccion preliminar de fraude puede mejorar tiempos, pero roza decisiones con efecto economico directo sobre el asegurado. Si el sistema perfila, prioriza o sugiere rechazo, entran preguntas serias sobre explicabilidad, supervison humana y sesgo. GDPR art. 22 no prohibe toda automatizacion, pero restringe decisiones basadas unicamente en tratamiento automatizado que produzcan efectos juridicos o afecten significativamente de modo similar, salvo determinadas excepciones y con garantias. Una pyme insurtech o una mediadora que delega demasiado en una IA puede terminar ofreciendo al cliente una respuesta impecablemente rapida y juridicamente coja. La velocidad no impresiona si luego no puedes explicar por que un expediente fue marcado como sospechoso.

En fintech, la presion es doble: crecimiento rapido y dependencia mas intensa de terceros cloud, APIs y herramientas embebidas. Eso multiplica la superficie de fallo. DORA art. 28 vuelve a ser decisivo porque la gestion de terceros TIC no se satisface con un cuestionario de seguridad de una pagina. Si la IA de soporte al fraude, conciliacion o KYC la presta un tercero que a su vez depende de otro para el modelo base y de otro para el hosting, la fintech necesita entender esa cadena. No para decorar el repositorio de riesgos, sino porque un fallo, cambio de servicio o incidente de seguridad en cualquiera de esos niveles puede afectar funciones criticas. Y una fintech pequena tiene un problema adicional: suele tener menos poder de negociacion para exigir logs, auditorias o localizacion del tratamiento. El proveedor vende “innovacion”. El contrato, en cambio, a veces parece escrito para que nadie pregunte nada.

En infraestructura critica y su ecosistema de proveedores pequenos, el riesgo de IA deja de ser sobre todo de privacidad y pasa a tocar disponibilidad e integridad. NIS2 art. 21 menciona expresamente seguridad en adquisicion, desarrollo y mantenimiento, gestion de vulnerabilidades y continuidad. Si un pequeno integrador usa IA para asistir configuraciones, generar scripts o resumir alertas en entornos OT o mixtos IT/OT, un error de salida no es solo un bug simpatico. Puede convertirse en una configuracion insegura, un cambio mal validado o una respuesta tardia ante un incidente. Aqui la vieja division entre “herramienta de productividad” y “sistema que afecta operacion” se derrumba bastante deprisa.

Hay otra consecuencia sectorial menos visible y mas molesta: el coste de evidencia. Cuanto mas regulado el sector, mas caro resulta demostrar que hiciste las cosas bien. Un despacho pequeno que usa IA para redactar propuestas tiene un problema de confidencialidad y calidad. Una fintech o una correduria tiene ademas que demostrar controles, decisiones, responsables y evaluaciones. Eso exige inventario, due diligence, clausulado, registros de acceso, politicas de uso, criterios de escalado y, en algunos casos, pruebas de supervision humana. La IA barata deja de ser tan barata en cuanto alguien pide la documentacion.

CSRD art. 1 puede parecer lejano para muchas pymes, pero empieza a importar por arrastre en cadenas de valor. Las grandes empresas sujetas a reporting de sostenibilidad y gobierno estan pidiendo a proveedores informacion sobre riesgos, controles y gobernanza. Si una pyme quiere seguir suministrando a un banco, una aseguradora o un operador esencial, la pregunta ya no sera solo si usa IA, sino como la gobierna, que terceros intervienen y que riesgos de ciberseguridad y privacidad ha identificado. El mercado esta convirtiendo obligaciones de unos en cuestionarios infernales para otros. No es muy poetico, pero funciona asi.

Que deberia hacer de verdad un equipo de seguridad y compliance cuando descubre uso descontrolado de IA

La escena es perfectamente plausible. Un responsable de compliance recibe una consulta trivial sobre una herramienta de transcripcion. Tirando del hilo descubre que comercial usa un asistente generativo para redactar ofertas, RR. HH. para cribar CV y soporte para resumir tickets. Nadie ha pasado por compras. Nadie ha revisado el contrato. Y al menos una de esas herramientas permite retener prompts para mejora del servicio. A partir de ahi, improvisar una circular interna de “sed prudentes” no arregla nada.

El primer paso no es prohibir por reflejo. Es contener con criterio. NIST CSF 2.0 ID.AM y GV.RM dan una pista simple: identifica activos, procesos, datos y riesgos antes de rediseñar controles. En terminos operativos, eso exige un inventario express de uso real en no mas de dos semanas. Que herramientas se estan usando, por quien, para que caso, con que datos, bajo que cuenta y con que integraciones. Si no distingues entre un empleado que usa IA para corregir estilo y otro que sube anexos contractuales con datos de clientes, mezclaras riesgos distintos y perderas tiempo.

Segundo paso: clasificar los casos por criticidad y base juridica. Aqui GDPR art. 30 ayuda aunque muchos lo recuerden solo para el registro de actividades. Si un uso de IA supone tratamiento de datos personales, debe vincularse a una actividad concreta, finalidad, categorias de datos y destinatarios. Los casos con datos sensibles, decisiones laborales, datos financieros o informacion confidencial de clientes deben escalar primero. Si ademas puede haber decisiones automatizadas relevantes, hay que revisar GDPR art. 22 y valorar si hace falta una evaluacion bajo GDPR art. 35. No todo uso de IA exige DPIA. Pero varios de los mas problemáticos, si.

Tercer paso: revisar al proveedor como si fuera proveedor de verdad, porque lo es. DORA art. 28 y NIS2 art. 21 empujan en la misma direccion aunque la empresa no este formalmente bajo ambos regímenes: due diligence de terceros, condiciones contractuales, localizacion del tratamiento, subprocesadores, seguridad, soporte, notificacion de incidentes y salida. Si la herramienta no ofrece DPA, no precisa retencion o no permite excluir el uso de datos para entrenamiento cuando eso es necesario, el caso de uso deberia suspenderse o migrarse. No por purismo legal. Porque no puedes controlar un riesgo cuyo flujo contractual es opaco.

Cuarto paso: establecer un patron de uso permitido y otro prohibido. Aqui la politica debe ser corta y ejecutable, no un ensayo sobre etica digital. Tres bloques suelen bastar. Uno, datos nunca permitidos en herramientas no aprobadas: datos de clientes identificables, categorias especiales, credenciales, secretos comerciales, codigo fuente sensible, documentos regulatorios no publicados. Dos, usos permitidos con controles: borradores anonimizados, ideacion, resumen de texto no confidencial, automatizacion interna acotada. Tres, requisitos tecnicos: SSO, MFA, logging, retencion minima, opcion de no entrenamiento, control de plugins e integraciones. ISO 27001 anexo A encaja bien aqui porque obliga a aterrizar controles de acceso, uso aceptable, gestion de la informacion y relacion con proveedores.

Quinto paso: preparar respuesta a incidente especifica para IA. GDPR art. 33 da 72 horas para notificar violaciones de seguridad de los datos personales a la autoridad de control cuando sea probable un riesgo para los derechos y libertades. NIS2 art. 23 fija alerta temprana en 24 horas para incidentes significativos. Eso significa que el playbook debe contemplar escenarios como estos: empleado que sube base de clientes a un chatbot; integracion API expuesta por mala configuracion; salida de la IA que induce a un pago fraudulento; proveedor que confirma acceso no autorizado a prompts almacenados. El equipo necesita decidir rapido si hubo datos personales, cuantos afectados potenciales, si existe evidencia de exfiltracion, si el tercero conserva logs y si el proceso afectado era critico. Sin esa lista minima, las primeras 24 horas se evaporan entre reuniones y capturas de pantalla.

Sexto paso: supervision humana de los casos que tocan clientes, empleo, fraude o finanzas. Aqui el AI Act art. 14, sobre supervision humana en sistemas de alto riesgo, sirve como referencia util incluso antes de entrar a discutir si el caso encaja o no formalmente en alto riesgo. La regla operativa sensata es simple: ninguna salida de IA deberia ejecutar por si sola rechazo de candidato, comunicacion de fraude, respuesta juridica vinculante, bloqueo de cuenta o cambio contractual sin revision humana trazable. El problema no es solo el sesgo. Es la falsa autoridad de un texto bien escrito. La IA se equivoca con una seguridad envidiable, y eso en operaciones hace daño.

Ultimo paso: formar, pero con ejemplos reales y consecuencias concretas. Decir “no metas datos confidenciales” sirve de poco si el empleado no sabe que un numero de poliza, un audio con nombre y telefono, o una consulta de soporte con capturas puede ser dato personal o informacion sensible. Una hora de formacion con cinco casos reales de la empresa vale mas que un codigo etico de veinte paginas. Y si la direccion no valida el mensaje, volvera a ocurrir. DORA art. 13, sobre respuesta y recuperacion, y NIS2 art. 20, sobre responsabilidades de los organos de direccion, comparten una leccion poco romantica: la ciberseguridad deja de ser “del equipo tecnico” en cuanto afecta continuidad, notificacion y gobierno.

El segundo mapa regulatorio que conviene tener a mano: identidad, certificacion y producto seguro por defecto

Hay una razon por la que muchas discusiones sobre IA en pymes se quedan cortas: se concentran en datos y se olvidan de identidad, confianza y seguridad del producto. Justo donde aparecen algunos de los fraudes mas eficaces. Si una pyme adopta IA para automatizar comunicaciones, aprobaciones o asistencia al cliente, la pregunta ya no es solo que datos entran en el sistema, sino como se autentica la accion, como se prueba su origen y que garantias tecnicas ofrece la tecnologia comprada.

La capa de identidad importa mucho cuando la IA se usa para generar o intermediar mensajes con apariencia corporativa. eIDAS 2.0, a traves de la revision del marco europeo de identidad digital y servicios de confianza, refuerza el valor juridico y operativo de mecanismos de autenticacion y firma para transacciones electronicas. No hace falta convertir cada correo en una ceremonia notarial, pero si entender que en procesos sensibles la diferencia entre “mensaje creible” y “instruccion autentica” puede depender de un servicio de confianza cualificado, de una firma electronica o de un sello electronico bien implementado. Las pymes que empiecen a usar IA para generar comunicaciones de cobro, cambios contractuales o aprobaciones internas harian bien en separar contenido y autorizacion. Una IA puede redactar. No deberia autenticar por si misma nada relevante.

El Cybersecurity Act art. 46 establece el marco europeo de certificacion de ciberseguridad. No obliga de forma general a que toda herramienta de IA venga certificada, pero cambia la conversacion de compras y due diligence. Si un proveedor presume de seguridad “enterprise-grade” y luego no puede demostrar conformidad con esquemas reconocibles, la pyme tiene una pista util sobre la distancia entre marketing y controles verificables. En sectores regulados o en cadenas de suministro exigentes, preguntar por certificaciones, aseguramiento y alcance real de auditorias deja de ser postureo. Es una forma barata de filtrar humo.

El Cyber Resilience Act art. 13 vuelve a aparecer aqui por una razon distinta: obliga a requisitos esenciales de ciberseguridad para productos con elementos digitales durante su ciclo de vida. La implicacion practica para pymes usuarias es menos exotica de lo que parece. A la hora de comprar una herramienta con funciones de IA integradas, conviene exigir cuatro respuestas que pronto seran basicas: como gestiona vulnerabilidades, cuanto tarda en publicar parches, como notifica fallos de seguridad y que configuracion segura viene activada por defecto. Ese “por defecto” importa mucho. La historia de la tecnologia esta repleta de productos vendidos como innovadores y desplegados con la puerta lateral abierta. La IA no esta corrigiendo esa tradicion precisamente.

Si la pyme opera en salud o trabaja con datos sanitarios para terceros de EE. UU., HIPAA 45 CFR 164.308(a)(1) obliga a un analisis de riesgos y a implementar medidas de seguridad para ePHI. Y HIPAA 45 CFR 164.312, sobre salvaguardas tecnicas, toca acceso, auditoria e integridad. No es una regulacion europea, pero para proveedores transatlanticos de servicios, software o BPO con IA aplicada a transcripcion medica, soporte o clasificacion documental, la leccion es directa: no puedes meter informacion sanitaria en herramientas generativas sin un control estricto de quien accede, que se registra y que garantias contractuales existen. La tecnologia podra ser puntera; la sancion por descuidar ePHI suele ser bastante vintage en su brutalidad.

Tambien merece atencion ISO 27001 anexo A en su parte de logging, control de acceso, relacion con terceros y proteccion de datos. No porque la certificacion resuelva por arte de magia el riesgo de IA, sino porque obliga a formalizar una disciplina que muchas pymes no tienen: quien aprueba herramientas, que excepciones existen, como se revisan privilegios, que evidencias se conservan y como se tratan los incidentes. Cuando aparece un fraude apoyado en deepfake de voz o en instrucciones falsas generadas con contexto interno, esas evidencias marcan la diferencia entre aprender algo y no enterarte de por donde te han entrado.

La conclusion practica de este segundo mapa es poco grandilocuente y bastante util. Si tu empresa esta adoptando IA, no te limites a revisar privacidad y licencias. Revisa identidad, prueba de origen, seguridad del producto, certificacion y capacidad de auditoria. El fraude moderno no siempre necesita vulnerar un sistema. A veces le basta con imitar una voz, redactar un mensaje impecable y aprovechar una cadena de confianza mal diseñada. Y si la pyme ha automatizado la forma pero no ha reforzado la autenticidad, el atacante ni siquiera necesita ser brillante. Solo necesita llegar primero.