Advertencia de Robert M. Lee sobre la IA: la infraestructura crítica está adoptando la IA más rápido de lo que puede detectar los riesgos
Robert M. Lee emitió una advertencia sobre la IA después de que Dragos descubriera que solo el 30 % de las redes de tecnología operativa tenían visibilidad de sus entornos. La advertencia de Robert M. Lee sobre la IA apunta a un conflicto creciente dentro de los servicios públicos, las fábricas, los centros de datos y los sistemas energéticos. Los operadores están incorporando software autónomo antes de que muchos puedan observar de forma fiable sus equipos existentes.
Lee, CEO y cofundador de Dragos, sostiene que la adopción de la IA avanza más rápido que la supervisión de seguridad en la tecnología operativa. La tecnología operativa, u OT, incluye el hardware y el software que controlan procesos físicos. A diferencia de una aplicación de oficina convencional, un fallo de OT puede interrumpir la electricidad, el agua, la fabricación, el transporte u otro servicio esencial.
No se trata simplemente de otra advertencia sobre delincuentes que usan IA. El problema más difícil surge al incorporar IA a entornos que ya contienen equipos heredados, inventarios incompletos y una supervisión deficiente. La IA puede mejorar las previsiones y la eficiencia, pero también puede ocultar por qué cambió un proceso físico.
Esta disyuntiva sitúa a los operadores de infraestructura entre la presión por una automatización más rápida y la disciplina de ingeniería necesaria para operar con seguridad. Los atacantes también están estudiando los sistemas de control con mayor atención. Por tanto, la carrera no enfrenta la adopción de IA con la resistencia a la tecnología. Enfrenta la automatización rápida con la visibilidad operativa.
La advertencia de Lee lleva el debate sobre la IA a las operaciones físicas
El cambio importante es que la IA está pasando de herramientas de asesoramiento a sistemas capaces de influir en procesos físicos.
Lee expuso su argumento en un análisis sobre infraestructura del 11 de septiembre de 2026 publicado por el Foro Económico Mundial. Describió aplicaciones de IA que están entrando en plantas de fabricación, redes eléctricas, centros de datos, instalaciones de baterías, sitios de energía renovable y operaciones mineras.
Algunas implementaciones todavía ayudan a las personas a revisar datos o prever necesidades de mantenimiento. Otras se están acercando al bucle de control, el proceso de retroalimentación que conecta sensores, decisiones y equipos físicos. Ese cambio modifica las posibles consecuencias de un error.
Una recomendación equivocada en un panel puede revisarse antes de que alguien actúe. Un controlador automatizado puede modificar el comportamiento de un equipo antes de que un operador comprenda el razonamiento. Una mayor autonomía acorta la distancia entre la salida de un modelo y un resultado físico.
Los consejos de administración y los ejecutivos tienen razones importantes para adoptar estos sistemas. La IA puede ayudar a prever la demanda, optimizar el uso de la energía, detectar comportamientos anómalos de los equipos y priorizar el mantenimiento. Los operadores de infraestructura también afrontan escasez de personal, equipos envejecidos y exigencias de mayor eficiencia.
Estos beneficios generan presión para acortar los calendarios de validación. Lee advierte que la misma presión puede reducir el escrutinio de nuevos proveedores e incrementar la complejidad de los sistemas. La organización incorpora otra capa de decisión mientras su equipo de seguridad puede seguir careciendo de un inventario completo de activos.
Los sistemas subyacentes ya han atravesado varias transiciones tecnológicas. Los controles mecánicos se convirtieron en sistemas digitales. Las redes industriales aisladas adquirieron conexiones con redes empresariales, servicios remotos y dispositivos de protocolo de internet.
Cada transición creó capacidades útiles y nuevas dependencias. Muchas organizaciones no lograron una visibilidad completa antes de que llegara la siguiente transición. La IA entra ahora en ese entorno aún inacabado.
El riesgo no se limita a que un modelo produzca una respuesta incorrecta. El modelo puede depender de datos externos, servicios en la nube, interfaces de programación de aplicaciones o actualizaciones de proveedores. Cada dependencia crea otra vía de fallo que los operadores deben comprender.
Un servicio de IA podría desaparecer durante un fallo del proveedor o una corrección del mercado. Una actualización del modelo podría cambiar comportamientos que los ingenieros habían probado previamente. Datos comprometidos podrían distorsionar las recomendaciones sin generar un error de software evidente.
La infraestructura crítica no puede tratar esas posibilidades como un tiempo de inactividad habitual de una aplicación. Los operadores deben preservar estados seguros, procedimientos manuales y pruebas fiables para las investigaciones de incidentes. La advertencia de Robert M. Lee sobre la IA sitúa estos requisitos operativos en el centro del debate.
Lee no pide a los propietarios de infraestructura que rechacen la IA. Sostiene que la gobernanza, la visibilidad y la planificación ante fallos deben llegar antes de una autonomía más profunda. De lo contrario, la adopción puede aumentar la incertidumbre dentro de sistemas donde la incertidumbre ya tiene consecuencias físicas.
El riesgo de infraestructura de IA de Dragos comienza con la falta de visibilidad
La IA no crea todas las debilidades de infraestructura, pero puede multiplicar las consecuencias de las debilidades que los defensores no pueden ver.
Los hallazgos sobre amenazas de 2026 que respaldan el argumento de Lee describen una grave brecha de visibilidad. Dragos afirma que solo el 30 % de las redes OT evaluadas tenía suficiente visibilidad de sus entornos. También informa que el 56 % no podía ver más allá del límite entre IT y OT.
La empresa afirma que el 88 % tenía dificultades con la detección y la respuesta. Estas cifras proceden de Dragos, un proveedor de seguridad OT, y no de un censo gubernamental independiente. Deben considerarse hallazgos derivados de los clientes, las investigaciones y la telemetría de la empresa.
Incluso con esa limitación, el patrón importa. Una organización no puede proteger activos que no ha identificado. Tampoco puede investigar actividad sospechosa cuando el tráfico de red, los cambios en controladores y las acciones de ingeniería nunca se registraron.
Esto crea un riesgo específico de infraestructura de IA de Dragos. Los nuevos sistemas de IA pueden añadir flujos de datos, componentes de software, credenciales y conexiones externas. También pueden tomar decisiones sobre equipos que utilizan protocolos industriales especializados.
La supervisión tradicional de IT no siempre interpreta esos protocolos ni los procesos físicos. Un equipo de seguridad corporativa podría detectar un inicio de sesión inusual sin comprender si cambió una bomba, un relé, una turbina o una línea de producción. La supervisión nativa de OT conecta la actividad cibernética con el comportamiento esperado de los equipos.
Dragos afirma que las organizaciones con visibilidad OT integral detectaron y contuvieron incidentes de ransomware en un promedio de cinco días. Lee contrastó esa cifra con un promedio de 42 días en toda la industria. La comparación sugiere que la visibilidad puede reducir de forma sustancial la ventana de operación de un atacante.
Sin embargo, no establece que la supervisión por sí sola causara la diferencia. Las organizaciones con una visibilidad más amplia también pueden contar con mejor personal, segmentación, planes de incidentes y apoyo ejecutivo. Las cifras muestran una asociación que merece atención, no una garantía universal de rendimiento.
El problema de visibilidad se vuelve más difícil cuando la IA introduce decisiones probabilísticas en lugar de deterministas. La lógica de control tradicional suele seguir reglas definidas que los ingenieros pueden inspeccionar. Un sistema de aprendizaje automático puede responder de forma distinta cuando cambian sus entradas, su modelo o el contexto que lo rodea.
Esa variabilidad no hace que la IA sea insegura automáticamente. Sí hace que las pruebas y la documentación sean más exigentes. Los operadores necesitan registros que muestren qué versión del modelo se ejecutó, qué datos recibió, qué acción recomendó y si una persona la aprobó.
También deben distinguir el comportamiento del modelo de la interferencia maliciosa. Una acción inesperada podría proceder de datos corruptos, una cuenta comprometida, una instrucción insegura, un defecto de software o una variación normal del modelo. Sin registros suficientes, esos escenarios pueden parecer idénticos.
Por tanto, las organizaciones de infraestructura deberían mapear cada dependencia de IA antes de asignarle autoridad operativa. Ese mapa incluye datos de entrenamiento y operativos, proveedores de modelos, servicios en la nube, integraciones, usuarios, credenciales, canales de actualización y activos físicos afectados.
Este trabajo se parece a crear una base de conocimiento técnico con capacidad de búsqueda, pero los requisitos son más estrictos. Los equipos necesitan registros controlados, una propiedad clara y procedimientos de recuperación probados. Una base de conocimiento de ingeniería más amplia puede respaldar la documentación, pero no sustituye la supervisión de seguridad OT.
La visibilidad también tiene una dimensión humana. Los operadores deben saber cuándo está activa la automatización y qué autoridad tiene. Los equipos de seguridad necesitan suficiente conocimiento de los procesos para reconocer cuándo un comando técnicamente válido crea un estado físico inseguro.
El objetivo no es registrar más datos sin un propósito. Es preservar suficiente contexto para la detección, la intervención y el análisis de la causa raíz. La seguridad de la infraestructura crítica con IA depende de esas pruebas durante toda la vida operativa del sistema.
Los atacantes están mapeando los mismos bucles de control en los que entrará la IA
Los operadores de infraestructura están añadiendo inteligencia a los entornos de control mientras los adversarios aprenden cómo se comportan esos entornos.
Dragos informa de que siguió a 26 grupos de amenazas OT durante su ciclo de informes de 2026. Afirma que los adversarios fueron más allá del acceso básico y comenzaron a mapear bucles de control. Ese trabajo incluyó identificar estaciones de trabajo de ingeniería y recopilar archivos de configuración o datos de alarmas.
Un archivo de configuración puede revelar cómo se comunican los equipos industriales y qué límites rigen un proceso. Los datos de alarmas pueden mostrar qué consideran anómalo los operadores. Las estaciones de trabajo de ingeniería suelen proporcionar acceso privilegiado a controladores y otros activos sensibles.
Este reconocimiento importa porque interrumpir un proceso físico exige más que entrar en una red. Los atacantes deben comprender los equipos, los tiempos, los controles de seguridad y las dependencias operativas. Un mapeo detallado reduce esa barrera de conocimiento.
Lee identificó a ELECTRUM y KAMACITE como ejemplos de grupos que buscan esta comprensión más profunda. Dijo que KAMACITE pasó meses mapeando bucles de control en infraestructuras de Estados Unidos. ELECTRUM había atacado previamente la red eléctrica de Ucrania y siguió desarrollando capacidades contra sistemas energéticos.
Según Lee, ELECTRUM atacó recursos energéticos distribuidos en Polonia durante diciembre de 2025. Esos recursos incluían sistemas de gestión de energía renovable. Se parecen a los entornos en los que los operadores desean cada vez más que la IA optimice la producción y el almacenamiento.
Esto no significa que la IA causara ese incidente. Muestra que los entornos de control subyacentes ya atraen a adversarios capaces. Añadir automatización mal gobernada podría aumentar la cantidad de componentes que los atacantes pueden estudiar o manipular.
La IA también cambia la economía del trabajo ofensivo. Los modelos pueden ayudar con el análisis de código, el reconocimiento, la traducción, la revisión de documentación y la creación de scripts. Pueden ayudar a atacantes menos experimentados a comprender equipos desconocidos con mayor rapidez.
Informes recientes sugieren que la IA suele acelerar técnicas existentes en vez de inventar otras completamente nuevas. Los atacantes siguen beneficiándose de dispositivos expuestos, credenciales predeterminadas, segmentación débil y aplicación tardía de parches. La IA puede ayudarles a encontrar y explotar esas debilidades conocidas con mayor rapidez.
Esta distinción evita que la historia derive hacia la ciencia ficción. Una empresa de servicios públicos no necesita enfrentarse a una superinteligencia totalmente autónoma para sufrir un peligro relacionado con la IA. Un grupo dirigido por personas que utiliza IA para ampliar el reconocimiento rutinario puede generar presión inmediata.
La oportunidad defensiva es igualmente real. La IA puede ayudar a los equipos de seguridad a priorizar alertas, analizar grandes conjuntos de datos, identificar secuencias inusuales y recuperar contexto técnico. Estos usos pueden ser valiosos cuando personas cualificadas conservan la autoridad sobre las acciones de mayor impacto.
El conflicto surge cuando las organizaciones tratan la IA defensiva como un sustituto de los controles fundamentales. Un modelo de alertas no puede compensar un acceso remoto no gestionado. El análisis automatizado no puede recuperar registros que la organización nunca recopiló.
Los principios de seguridad OT de CISA hacen hincapié en decisiones que preserven entornos operativos seguros y protegidos. La guía es anterior a esta advertencia concreta, pero sus prioridades siguen siendo pertinentes.
Los propietarios de infraestructuras siguen necesitando inventarios precisos de activos, configuraciones seguras, segmentación de red, acceso remoto controlado y respuesta a incidentes probada. La IA debe operar dentro de esos controles. No debe convertirse en un atajo para sortearlos.
El patrón de despliegue más sólido asigna a la IA responsabilidades limitadas y observables. Un modelo podría clasificar casos de mantenimiento sin modificar directamente los equipos. Podría redactar un resumen de investigación mientras los analistas verifican sus evidencias.
Los sistemas de mayor riesgo requieren límites más sólidos. Los operadores pueden restringir comandos, imponer límites de seguridad deterministas, exigir aprobación humana y aislar funciones críticas. También pueden probar cómo se comporta el sistema cuando los datos dejan de estar disponibles o resultan engañosos.
Este enfoque trata la IA como un componente de un sistema de seguridad, no como el operador incuestionable del sistema. Preserva las ventajas de un análisis más rápido y limita la vía que puede llevar de un fallo del modelo a una interrupción física.
La advertencia sobre IA de Robert M. Lee expone una disyuntiva de automatización
La decisión principal no es si usar IA, sino si la automatización seguirá siendo observable, reversible y subordinada a los controles de seguridad.
La advertencia sobre IA de Robert M. Lee describe una disyuntiva que los despliegues empresariales convencionales pueden ocultar. Una mayor autonomía puede reducir las cargas de trabajo y los tiempos de respuesta. También puede reducir el tiempo disponible para que una persona cuestione una decisión insegura.
Los operadores de infraestructuras llevan mucho tiempo gestionando la automatización mediante revisiones de ingeniería, controles de cambio, redundancia y diseño a prueba de fallos. La IA no invalida esas prácticas. Aumenta la necesidad de aplicarlas cuidadosamente.
Un despliegue debe comenzar con un problema operativo definido. Los equipos deben indicar a qué puede acceder el modelo, qué puede recomendar y qué puede modificar. También deben identificar las acciones que el modelo nunca puede realizar.
Estos límites necesitan aplicación técnica. Un documento de políticas no puede impedir que una integración con privilegios excesivos emita comandos. Los controles de acceso, la arquitectura de red y los sistemas de seguridad deben limitar la autoridad real del modelo.
Las pruebas deben abarcar más que la precisión media. Los operadores necesitan escenarios con sensores ausentes, entradas corruptas, instrucciones contradictorias, servicios en la nube no disponibles y estados inesperados de los equipos. Deben probar la recuperación después de que falle el componente de IA.
El marco de riesgos de IA de NIST organiza el trabajo sobre riesgos en torno a la gobernanza, el mapeo, la medición y la gestión. En abril de 2026, NIST también anunció trabajos sobre un perfil de infraestructura crítica para el marco.
Ese perfil pretende ayudar a los operadores de infraestructuras a traducir los principios de IA fiable en prácticas específicas para cada sector. Su desarrollo indica que las políticas generales de IA no bastan para las operaciones físicas. La energía, el agua, el transporte y la manufactura enfrentan consecuencias y limitaciones diferentes.
NIST también considera la seguridad y la resiliencia como características fundamentales de una IA fiable. La resiliencia significa que un sistema puede soportar problemas y recuperarse sin daños inaceptables. Para un despliegue industrial, eso incluye operar de forma segura cuando el modelo no está disponible.
Por tanto, la operación manual sigue siendo una prueba importante. Los equipos deben saber si el personal puede mantener los servicios esenciales tras perder un proveedor de IA, un endpoint de modelo o un conjunto de datos de apoyo. También necesitan estimaciones realistas de cuánto tiempo puede durar esa alternativa.
Una alternativa manual que solo existe en la documentación puede fallar durante una emergencia. Los operadores deben practicarla en condiciones controladas. La rotación de personal, los cambios de equipos y la creciente automatización pueden volver silenciosamente inutilizables los procedimientos antiguos.
La continuidad del proveedor plantea otra preocupación. Un operador de infraestructura puede depender de una startup, un modelo propietario o una integración en la nube que cambia rápidamente. Las garantías contractuales no pueden sustituir los planes técnicos de salida.
Las organizaciones deben conservar los datos y la configuración necesarios para migrar lejos de un proveedor. Deben entender qué funciones se detienen cuando desaparece un servicio. También necesitan controles para las actualizaciones que podrían alterar comportamientos validados.
La gobernanza de datos forma parte del mismo plan operativo. Las herramientas de IA pueden exponer detalles sensibles de red, documentación de equipos o información sobre incidentes cuando los equipos envían material a servicios externos. Los prompts no controlados pueden convertirse en otra vía de exfiltración de datos.
Un flujo de trabajo de información gobernado puede ayudar a los equipos a organizar material aprobado y reducir la gestión dispersa. Los operadores de infraestructura crítica siguen necesitando controles específicos del sector que regulen la clasificación, la retención, el acceso y el procesamiento externo.
La pregunta escéptica es si los proveedores y operadores pueden validar modelos que cambian rápidamente con el rigor esperado para equipos industriales de larga vida útil. Los modelos pueden actualizarse mensualmente mientras los sistemas de control siguen desplegados durante décadas. Esos plazos no encajan de forma natural.
Ningún marco puede eliminar ese desajuste. Los operadores deben gestionarlo mediante control de versiones, pruebas repetibles, despliegue gradual, supervisión y capacidad de reversión. Deben asumir que el comportamiento del modelo y las condiciones de amenaza cambiarán.
La seguridad de la infraestructura crítica con IA depende, por tanto, de limitar las sorpresas. Los equipos no pueden predecir todos los fallos, pero pueden preservar las evidencias, los límites de autoridad y las vías de recuperación segura. Esas capacidades determinan si una anomalía se convierte en un incidente gestionable o en una interrupción inexplicada.
La regulación avanza, pero los operadores no pueden esperar un manual perfecto
La orientación gubernamental reconoce cada vez más el riesgo, pero la responsabilidad sigue recayendo en los operadores que toman decisiones de despliegue ahora.
La hoja de ruta de seguridad de IA de CISA aborda explícitamente la adopción de IA en infraestructuras críticas. La agencia afirmó que el despliegue podría aumentar la exposición a fallos, ataques físicos y ciberataques.
La hoja de ruta pidió prácticas de seguridad desde el diseño, red teaming, gestión de vulnerabilidades y colaboración con las partes interesadas de las infraestructuras. Estos objetivos establecieron una dirección. No crearon requisitos técnicos vinculantes para todos los sectores o despliegues.
La regulación de infraestructuras críticas está fragmentada porque los sectores difieren considerablemente. Una red eléctrica, una empresa de agua, un hospital, un oleoducto y una red de transporte no comparten tecnología ni modelos de riesgo idénticos. La propiedad y la autoridad reguladora también varían.
Esa fragmentación puede producir una gobernanza de IA desigual. Un gran operador puede crear un programa especializado de revisión. Una pequeña empresa municipal de servicios públicos puede depender de las garantías de un proveedor porque carece de experiencia en seguridad de IA.
Aquí es donde la advertencia sobre IA de Robert M. Lee presiona a los consejos de administración y a los equipos de compras. No pueden asumir que los reguladores o los proveedores de modelos han resuelto todos los riesgos operativos. Las decisiones de compra se convierten en decisiones de arquitectura de seguridad.
Los contratos deben exigir documentación sobre dependencias de modelos, procesos de actualización, incidentes de seguridad, gestión de datos y obligaciones de soporte. Los operadores también necesitan el derecho a probar sistemas y recibir información sobre cambios significativos.
La evaluación independiente puede ayudar, pero el evaluador debe comprender OT. Una evaluación genérica de aplicaciones puede pasar por alto la seguridad de los procesos, el comportamiento de los controladores o la recuperación operativa. La seguridad de infraestructuras requiere cooperación entre especialistas en ciberseguridad, ingenieros, proveedores y operadores de primera línea.
Los reguladores pueden mejorar la coherencia definiendo la evidencia mínima para los despliegues de mayor riesgo. Esa evidencia podría incluir modelos de amenazas, resultados de validación, requisitos de control humano, informes de incidentes y procedimientos de contingencia demostrados.
Aun así, el cumplimiento no debe convertirse en el único objetivo. Un sistema puede satisfacer una lista de verificación y, al mismo tiempo, dejar sin explorar dependencias físicas importantes. La pregunta relevante es si la organización puede mantener operaciones seguras durante un ataque, un error o la pérdida de un servicio.
El desafío económico sigue siendo considerable. Muchas organizaciones de infraestructura tienen personal limitado y equipos envejecidos. Los nuevos mandatos sin financiación ni apoyo para la implementación pueden generar papeleo sin una reducción significativa del riesgo.
Por eso importan los controles básicos. Los objetivos de rendimiento de CISA priorizan prácticas con un amplio valor de reducción de riesgos. Incluyen protecciones tanto para la tecnología de la información como para la tecnología operativa.
Los operadores deben establecer esos cimientos antes de otorgar a la IA una autoridad más amplia. La autenticación robusta, el acceso remoto seguro, la segmentación, las copias de seguridad, el registro de eventos y los planes de respuesta protegen los sistemas independientemente de si un incidente involucra IA.
Las políticas también deben distinguir entre categorías de riesgo de IA. Los atacantes pueden utilizar IA contra infraestructuras. Los adversarios pueden atacar un sistema de IA o sus datos. Un despliegue de IA también puede fallar sin que intervenga ningún atacante.
Estas categorías requieren controles diferentes. La inteligencia de amenazas ayuda frente a actividades maliciosas. La evaluación de modelos aborda el rendimiento y los modos de fallo. La gobernanza determina quién puede aprobar, supervisar, modificar o desactivar el sistema.
Tratar cada problema como un “ciberataque de IA” oculta esas diferencias. También puede fomentar compras costosas que no abordan la debilidad real. La clasificación clara de incidentes será cada vez más importante a medida que crezcan los despliegues.
La prueba regulatoria es si la orientación cambia el comportamiento operativo antes de que un gran fallo obligue a actuar. Publicar otro marco no basta. Las revisiones de adopción, los requisitos de compra, los ejercicios y las divulgaciones de incidentes mostrarán si la gobernanza se está haciendo realidad.
Tres señales mostrarán si la visibilidad logra ponerse al día
La próxima prueba es si los propietarios de infraestructuras desarrollan salvaguardas medibles antes de que la IA reciba un control más amplio sobre los sistemas físicos.
La primera señal es el perfil de infraestructura crítica de NIST para el Marco de Gestión de Riesgos de IA. Sus recomendaciones deberían traducir principios generales en acciones que los operadores puedan probar. Una guía específica sobre cambios de modelos, registro OT, operaciones de contingencia y dependencias de proveedores reforzaría el argumento de Lee.
Un perfil impreciso dejaría a las organizaciones interpretando el riesgo de formas distintas. Un perfil detallado, especialmente si lo adoptan los reguladores sectoriales y los compradores, crearía una base común. Eso reduciría el margen para despliegues apresurados respaldados únicamente por afirmaciones de proveedores.
La segunda señal es el avance en las métricas de visibilidad OT. Dragos informa actualmente que solo el 30% de las redes OT tienen visibilidad, mientras que el 56% no puede ver más allá del límite entre IT y OT. Los futuros informes deberían mostrar si esas cifras mejoran a medida que se expande la adopción de IA.
Una mejora sugeriría que las organizaciones están desarrollando supervisión antes de asignar mayor autonomía. Una visibilidad estancada junto a una adopción rápida reforzaría el riesgo de infraestructura de IA señalado por Dragos. Significaría que la complejidad está creciendo más rápido que la capacidad de los defensores para observarla.
La tercera señal es la primera oleada de incidentes de OT relacionados con la IA que se han dado a conocer. Los informes deben distinguir entre uso malicioso, ataques contra modelos, integraciones inseguras y fallos de software ordinarios. Sin ese nivel de detalle, las organizaciones no pueden identificar qué controles fallaron.
Un registro transparente de incidentes ayudaría a los operadores a aprender antes de enfrentarse al mismo problema. También permitiría comprobar si el registro actual admite un análisis significativo de la causa raíz. Los incidentes repetidamente inexplicados confirmarían la preocupación de Lee sobre la creciente presencia de puntos ciegos.
Los responsables de infraestructura no deberían esperar a que aparezcan las tres señales. Pueden inventariar ya los despliegues de IA, identificar los procesos físicos afectados y verificar quién tiene autoridad para detenerlos. También pueden probar las operaciones sin el modelo ni sus servicios externos.
Los desarrolladores deberían exigir interfaces claras, permisos restringidos, comportamientos versionados y registros de auditoría completos. Los compradores empresariales deberían pedir a los proveedores pruebas, en lugar de amplias promesas de seguridad. Los trabajadores del conocimiento deberían evitar enviar información sensible sobre infraestructuras a herramientas no aprobadas.
La advertencia de Robert M. Lee sobre la IA ofrece, en última instancia, una regla práctica para tomar decisiones. La automatización no debería adquirir autoridad operativa más rápido de lo que la organización adquiere visibilidad, control y capacidad de recuperación.
La IA aún puede mejorar los servicios críticos. Sin embargo, el despliegue debe seguir siendo lo suficientemente comprensible como para investigarlo y lo bastante limitado como para detenerlo. Antes de aprobar la próxima integración, formule una pregunta: si actúa incorrectamente mañana, ¿puede su equipo entender por qué y recuperarse de forma segura?
