La inteligencia artificial no está creando un problema de ciberseguridad nuevo; está acelerando uno que muchas empresas todavía no han entendido: su operación digital depende de conexiones, servicios y APIs que crecieron más rápido que su capacidad para gobernarlas. Cuando esas puertas invisibles quedan mal inventariadas, mal configuradas o protegidas por controles aislados, el atacante ya no necesita “entrar” como antes. Puede automatizar reconocimiento, probar comportamientos, saturar servicios y convertir una debilidad técnica en interrupción operativa, sobrecostos y pérdida de confianza. El verdadero riesgo, por tanto, no es solamente sufrir un ataque DDoS o descubrir una API vulnerable. Es comprobar, en medio del incidente, que tecnología, desarrollo, seguridad, proveedores y dirección nunca fueron diseñados para responder como un solo sistema. La pregunta empresarial ya no es si la IA será usada para atacar, sino si nuestra arquitectura puede resistir ataques que aprenden, escalan y se repiten. 👉 LEE NUESTRO BLOG...
Durante muchos años, la conversación sobre ciberseguridad empresarial estuvo dominada por conceptos relativamente visibles: antivirus, firewalls, contraseñas, copias de seguridad, phishing, malware y protección de servidores.
Todo eso continúa siendo importante.
Lo que ha cambiado es el lugar donde comienza a concentrarse una parte creciente del riesgo.
La empresa moderna ya no funciona únicamente mediante aplicaciones independientes. Funciona mediante conexiones.
El sistema de facturación habla con el ERP. El comercio electrónico consulta inventarios. El CRM intercambia información con formularios, plataformas de mensajería y automatizaciones. Las aplicaciones móviles consumen servicios externos. Los sistemas de inteligencia artificial utilizan datos, modelos, herramientas y aplicaciones mediante interfaces programáticas.
Esas conexiones se realizan, en gran medida, a través de APIs.
Y precisamente allí existe un problema que muchos comités directivos todavía observan como si fuera exclusivamente técnico.
No lo es.
Una API puede ser pequeña técnicamente y enorme empresarialmente
Una API —interfaz de programación de aplicaciones— permite que dos sistemas intercambien información o ejecuten determinadas acciones.
Puede consultar el estado de un pedido, autenticar un usuario, generar una factura, iniciar un pago, recuperar información de clientes, actualizar un inventario o permitir que un agente de inteligencia artificial realice una acción.
El empresario no necesita convertirse en desarrollador para comprender la implicación.
Necesita comprender algo mucho más importante:
cada API habilitada amplía la capacidad funcional de la organización, pero también incorpora una nueva relación que debe ser gobernada.
El problema comienza cuando las APIs se multiplican sin que exista una visión completa de cuáles están activas, quién es responsable de ellas, qué información utilizan, qué permisos poseen, cuáles dependen de terceros y qué sucedería si dejaran de estar disponibles.
La inteligencia artificial agrava esta situación porque está aumentando la velocidad con la cual las empresas conectan sistemas y automatizan decisiones.
Un estudio de Salt Security publicado en 2026 encontró que el 66 % de las organizaciones consultadas había incrementado su número de APIs en más del 50 % durante los doce meses anteriores.
Ese crecimiento puede representar innovación.
Pero crecimiento tecnológico sin gobierno también puede significar crecimiento acelerado de la superficie de ataque.
La IA no necesita inventar nuevos ataques para cambiar el riesgo
Existe una tendencia a imaginar el ciberdelito impulsado por inteligencia artificial como algo extraordinariamente sofisticado: sistemas autónomos descubriendo vulnerabilidades desconocidas y atacando organizaciones mediante técnicas completamente nuevas.
La realidad empresarial puede ser menos espectacular y, precisamente por ello, más peligrosa.
La IA permite hacer más rápido, con mayor frecuencia y a menor costo actividades que ya existían: reconocimiento, automatización de solicitudes, análisis de respuestas, generación de variaciones, identificación de patrones, exploración de endpoints y coordinación de ataques.
Akamai describe en su informe State of the Internet 2026 una industrialización de estas campañas: los atacantes combinan abuso de APIs, ataques contra aplicaciones web y DDoS de capa 7 en operaciones coordinadas. La compañía reportó un crecimiento promedio interanual del 113 % en ataques diarios contra APIs y un aumento del 104 % en ataques DDoS de capa 7 durante dos años.
La palabra importante aquí no es solamente “ataque”.
Es industrialización.
Significa repetibilidad.
Escala.
Automatización.
Menor costo operativo para quien ataca.
Y mayor presión para quien defiende.
Una organización puede tener buenas herramientas de seguridad y aun así encontrarse estructuralmente mal preparada si cada área observa una parte distinta del problema.
Si su empresa está incorporando IA, automatizaciones, aplicaciones conectadas o nuevos proveedores digitales, puede ser oportuno revisar no solamente qué tecnología posee, sino cómo está estructurada y gobernada. Una conversación consultiva puede comenzar aquí:
https://t.mtrbio.com/todo-en-unonet
El DDoS moderno no necesariamente pretende destruir; puede pretender desgastar
Cuando se menciona un ataque distribuido de denegación de servicio —DDoS— muchas personas imaginan una página web completamente caída durante horas.
Ese escenario continúa existiendo.
Pero sería un error limitar el análisis a la indisponibilidad total.
Los ataques de capa 7 pueden dirigirse contra funciones específicas de una aplicación: búsquedas, autenticaciones, procesos de compra, consultas, APIs o transacciones que demandan recursos significativos del sistema.
Esto introduce una lógica empresarial distinta.
Un atacante no siempre necesita apagar toda la compañía.
Puede resultarle suficiente degradar progresivamente la experiencia del cliente.
Aumentar los tiempos de respuesta.
Elevar el consumo de infraestructura en la nube.
Forzar escalamiento automático.
Generar costos.
Sobrecargar equipos.
Disparar falsas alarmas.
Dificultar la identificación de tráfico legítimo.
O afectar justamente la funcionalidad que genera ingresos.
Akamai ha advertido que los atacantes están utilizando automatización para degradar rendimiento y elevar costos de infraestructura, además de combinar ataques a aplicaciones, APIs y DDoS.
Eso cambia la conversación con la gerencia.
La ciberseguridad deja de ser solamente una pregunta acerca de “si nuestros datos están protegidos”.
También debe preguntar:
¿cuánto tiempo puede nuestra operación soportar una degradación tecnológica deliberada sin afectar ventas, servicio, costos, reputación y confianza?
El riesgo invisible: empresas que no saben exactamente qué deben proteger
Durante años he insistido en una idea que sigue teniendo absoluta vigencia: nunca la tecnología por la tecnología en sí misma; sino la tecnología por la funcionalidad.
Aplicada a ciberseguridad significa algo muy concreto.
No tiene sentido adquirir más herramientas si la empresa todavía no comprende su propia arquitectura.
Puede instalar un nuevo firewall.
Contratar otro servicio.
Incorporar inteligencia artificial al centro de operaciones de seguridad.
Añadir protección anti-DDoS.
Comprar una plataforma de monitoreo de APIs.
Todo puede ser técnicamente válido.
Pero ninguna herramienta sustituye una pregunta básica:
¿sabemos realmente qué tenemos?
El API Security Impact Study 2026 de Akamai señala que los incidentes relacionados con APIs alcanzaron al 87 % de las organizaciones estudiadas, mientras solo el 23 % afirmó conocer qué APIs devolvían información sensible. El mismo estudio encontró que apenas el 16 % integraba completamente pruebas de seguridad de APIs en sus procesos de desarrollo.
La situación latinoamericana merece atención especial.
En la edición regional del estudio, realizada con profesionales de ciberseguridad de Brasil y México, Akamai reportó que el 93 % de las empresas consultadas había experimentado algún incidente relacionado con APIs durante los doce meses anteriores. Entre los problemas estructurales señalados aparecen configuraciones incorrectas y controles de acceso insuficientes.
No conviene interpretar estas cifras como una invitación al miedo.
Conviene interpretarlas como una señal de administración.
Porque aquello que una empresa desconoce difícilmente puede gobernarlo.
La inteligencia artificial está convirtiendo las APIs en órganos ejecutores
Hay otra razón por la cual este tema trasciende el departamento de TI.
La generación anterior de inteligencia artificial empresarial se utilizaba principalmente para responder preguntas, analizar documentos, generar contenido o ayudar al trabajador a encontrar información.
Los nuevos sistemas de IA son progresivamente capaces de actuar.
Un agente puede consultar una base de datos.
Modificar un registro.
Enviar un mensaje.
Generar una orden.
Solicitar información.
Crear una tarea.
Actualizar una oportunidad comercial.
Activar un proceso.
Interactuar con sistemas externos.
¿Y cómo realiza muchas de esas acciones?
Mediante APIs.
Por eso proteger un sistema de IA ya no consiste solamente en proteger el modelo.
Debe protegerse también aquello que el modelo puede consultar, utilizar y ejecutar.
Akamai resume esta relación señalando que las APIs constituyen el “sistema nervioso” de muchas empresas modernas y permiten a los agentes ejecutar acciones reales sobre sistemas y datos.
Aquí aparece una frontera que los directivos necesitan comprender.
Antes, una respuesta incorrecta de IA podía significar una mala recomendación.
Cuando la inteligencia artificial obtiene capacidad de ejecución, una decisión incorrecta, una autorización excesiva o una API vulnerable puede convertirse en una acción.
La diferencia es enorme.
El verdadero problema está entre las áreas
Muchas vulnerabilidades sobreviven porque pertenecen a zonas organizacionales ambiguas.
Desarrollo piensa que seguridad revisará.
Seguridad supone que infraestructura controla.
Infraestructura considera que la aplicación pertenece al proveedor.
El proveedor protege su plataforma, pero no necesariamente la configuración particular del cliente.
El área de negocio solicita rapidez.
La dirección observa resultados.
Legal aparece después de un incidente.
Y mientras cada participante cumple parcialmente con su responsabilidad, nadie gobierna integralmente el sistema.
Ese modelo era frágil antes de la IA.
Con automatización ofensiva, resulta todavía más peligroso.
La respuesta no debería consistir en transformar todos los empleados en especialistas en ciberseguridad.
Debe consistir en establecer responsabilidades claras.
Toda API crítica debería tener propietario.
Toda integración debería tener propósito conocido.
Todo acceso debería responder al principio de mínimo privilegio.
Toda dependencia crítica debería contar con evaluación de continuidad.
Toda funcionalidad expuesta debería tener monitoreo.
Toda modificación significativa debería incorporar pruebas.
Todo incidente debería disponer de responsabilidades y escalamiento previamente definidos.
Y cada uno de esos componentes debería vincularse con el proceso empresarial que protege.
Si al realizar este ejercicio aparecen APIs desconocidas, dependencias sin responsable, servicios críticos sin pruebas de continuidad o controles que nadie puede explicar claramente, el problema no se resuelve comprando inmediatamente otra plataforma. Primero debe comprenderse la arquitectura actual. Ese diagnóstico puede abordarse de manera consultiva desde:
https://t.mtrbio.com/todo-en-unonet
La seguridad debe seguir el proceso, no solamente la infraestructura
Supongamos que una empresa vende por internet.
El análisis tradicional podría revisar servidor, aplicación, firewall, base de datos y plataforma de pagos.
Una mirada funcional pregunta algo diferente.
¿Qué necesita ocurrir desde que el cliente inicia una compra hasta que recibe confirmación?
¿Qué componentes intervienen?
¿Qué API consulta inventario?
¿Cuál procesa identidad?
¿Cuál calcula disponibilidad?
¿Cuál conversa con logística?
¿Qué terceros participan?
¿Qué información cruza cada conexión?
¿Qué ocurre cuando una API responde lentamente?
¿Cuándo se activa escalamiento?
¿Qué parte del proceso se convierte en cuello de botella durante un DDoS de capa 7?
¿Cuánto cuesta cada llamada si la infraestructura está basada en consumo?
¿Cuál funcionalidad podría aislarse sin detener todo el negocio?
¿Cuánto tiempo soportaría el proceso una interrupción?
Esta forma de analizar cambia la calidad de las decisiones porque la ciberseguridad comienza a hablar el idioma de la operación.
Eso es lo que necesita comprender la dirección.
No solamente cuántas vulnerabilidades existen, sino qué proceso empresarial puede fallar, cuánto impacto puede producir y qué capacidad de respuesta posee la organización.
Más tecnología no compensa una arquitectura desordenada
Es tentador responder a una nueva amenaza adquiriendo una nueva solución.
Sin embargo, la acumulación de herramientas también genera complejidad.
La empresa puede terminar con monitoreo en un proveedor, protección DDoS en otro, administración de identidades en otro, API gateway en otro, infraestructura cloud distribuida, aplicaciones desarrolladas internamente, plataformas SaaS contratadas directamente por áreas y automatizaciones conectadas sin inventario central.
Cada pieza individual puede ser excelente.
El conjunto puede ser difícil de gobernar.
Ahí aparece una contradicción frecuente de la transformación digital: empresas tecnológicamente avanzadas pero arquitectónicamente inmaduras.
Tienen muchas capacidades.
Pero poca visibilidad.
Muchas integraciones.
Pero propiedad difusa.
Muchos datos.
Pero clasificación insuficiente.
Muchas automatizaciones.
Pero controles fragmentados.
Mucha innovación.
Pero poca capacidad para responder una pregunta elemental:
si mañana esta conexión falla, ¿qué parte de mi empresa deja de funcionar?
Una Arquitectura Tecnológica Funcional cambia el orden de la conversación
Frente a este escenario, considero más útil pensar desde una Arquitectura Tecnológica Funcional (ATF).
No comienza preguntando qué producto de ciberseguridad comprar.
Comienza preguntando qué necesita proteger la empresa para continuar funcionando.
Primero se reconoce el ecosistema real: aplicaciones, infraestructura, APIs, datos, servicios externos, usuarios, agentes de IA, automatizaciones y dependencias.
Después se establece criticidad.
No todas las APIs tienen el mismo valor.
Una API que consulta información pública no representa el mismo riesgo que otra capaz de aprobar operaciones, consultar datos personales o ejecutar pagos.
Luego debe revisarse identidad y acceso.
No basta con que una conexión esté autenticada.
Debe determinarse qué puede hacer, durante cuánto tiempo, bajo qué condiciones y quién puede modificar esos permisos.
Después aparece la resiliencia.
¿Qué sucede bajo cargas anormales?
¿Existe limitación de solicitudes?
¿Hay capacidad para distinguir tráfico automatizado legítimo de abuso?
¿Los servicios críticos pueden aislarse?
¿Existe observabilidad suficiente para identificar comportamientos anómalos?
¿Los costos cloud pueden dispararse ante tráfico hostil?
¿Se conocen las dependencias de terceros?
Finalmente, aparece la capacidad de respuesta.
Una empresa preparada no improvisa responsabilidades durante un incidente.
Sabe quién decide.
Quién contiene.
Quién comunica.
Quién documenta.
Quién conversa con proveedores.
Quién evalúa afectación de datos.
Quién informa a clientes cuando corresponde.
Y quién determina cuándo la operación puede considerarse restaurada.
El consejo directivo también tiene responsabilidad en la resiliencia digital
No significa que la junta directiva deba aprender a configurar un WAF o interpretar registros de tráfico.
Significa que debe realizar mejores preguntas.
¿Cuáles son nuestros cinco servicios digitales más críticos?
¿Qué dependencias tecnológicas podrían detenerlos?
¿Cuántas APIs tenemos?
¿Cuántas son críticas?
¿Cuántas interactúan con inteligencia artificial?
¿Quién responde por ellas?
¿Cuándo fueron probadas?
¿Qué capacidad existe para soportar tráfico hostil?
¿Cuánto costaría una degradación durante cuatro, ocho o veinticuatro horas?
¿Cuándo realizamos el último ejercicio real de respuesta?
¿Qué proveedor podría convertirse en punto único de falla?
La madurez aparece cuando estas preguntas pueden responderse sin convocar durante tres semanas a personas de seis áreas diferentes.
Si nadie puede responderlas, ya existe un hallazgo.
La ventaja del atacante es la velocidad; la ventaja empresarial debe ser la claridad
No podremos impedir que los ciberdelincuentes utilicen inteligencia artificial.
Tampoco podremos evitar que existan botnets, automatización ofensiva, mercados de DDoS como servicio o nuevas herramientas capaces de explorar sistemas más rápidamente.
Pretender ganar únicamente aumentando herramientas defensivas conduce a una carrera interminable.
La ventaja sostenible de una organización reside en otra parte.
Conocer su arquitectura.
Reducir exposición innecesaria.
Controlar accesos.
Detectar anomalías.
Diseñar resiliencia.
Preparar respuestas.
Asignar responsables.
Integrar seguridad con desarrollo, operación, datos, legal y dirección.
Y revisar continuamente lo que cambia.
La IA continuará acelerando ambos lados de la ciberseguridad.
La pregunta estratégica no es quién tendrá la herramienta más impresionante.
Será quién posea la organización más preparada para utilizar tecnología sin perder control sobre ella.
La ciberseguridad ya forma parte del diseño empresarial
Una API vulnerable puede parecer un problema técnico hasta que expone información.
Un ataque DDoS puede parecer un problema de infraestructura hasta que detiene ventas.
Una mala configuración puede parecer un error operativo hasta que compromete clientes.
Una automatización puede parecer una mejora de productividad hasta que obtiene permisos que nunca debió tener.
Y una estrategia de inteligencia artificial puede parecer innovación hasta que descubre que depende de una arquitectura que nadie gobierna completamente.
Por eso debemos superar una idea que durante demasiado tiempo ha limitado la conversación: que seguridad significa proteger computadores.
Hoy significa proteger la capacidad de la empresa para operar, decidir, servir, cobrar, cumplir y conservar confianza en un entorno cada vez más automatizado.
Cuando observamos el problema desde allí, la solución cambia.
No comenzamos por comprar.
Comenzamos por comprender.
No comenzamos por instalar.
Comenzamos por priorizar.
No comenzamos por automatizar.
Comenzamos por determinar qué debe funcionar, qué puede fallar y qué nunca debería quedar sin control.
Esa es precisamente la diferencia entre incorporar tecnología y construir una empresa funcionalmente preparada para el futuro.
Si su organización está aumentando el uso de APIs, nube, automatización o inteligencia artificial, este es un buen momento para revisar si su arquitectura tecnológica está creciendo con el mismo orden que su innovación. Puede iniciar esa conversación estratégica con TODO EN UNO.NET en:
https://t.mtrbio.com/todo-en-unonet
La inteligencia artificial continuará evolucionando y los ataques también. Pero la respuesta empresarial no debería ser miedo ni acumulación indiscriminada de tecnología. Debe ser criterio, arquitectura, gobierno y capacidad de adaptación.
Porque el mayor riesgo no es que los atacantes aprendan a utilizar mejor la inteligencia artificial.
El mayor riesgo es que ellos conozcan las debilidades de nuestra arquitectura antes de que nosotros mismos las conozcamos.