Expertos federales instan a realizar pruebas rigurosas de IA antes de su despliegue
Google News ha vuelto a poner sobre la mesa una advertencia federal marcada por un conflicto claro: las agencias están desplegando más IA mientras las pruebas fiables siguen siendo costosas, lentas e incompletas.
El informe de fondo describe cómo expertos federales en tecnología instan a las agencias a probar la IA de forma reiterada antes de utilizarla en entornos de alto impacto. Su preocupación no se limita a las conocidas cuestiones sobre datos de entrenamiento sesgados. También quieren que las agencias examinen cómo se comportan los modelos con usuarios reales, información sensible, presión operativa y condiciones que los desarrolladores no anticiparon.
Esta posición desafía el impulso paralelo del gobierno federal por una adopción más rápida. Se ha pedido a las agencias que eliminen barreras innecesarias, modernicen los servicios y utilicen la IA comercial de forma más eficiente. Sin embargo, las mismas instituciones siguen siendo responsables cuando una recomendación automatizada, una verificación de identidad, un resumen o una acción de software perjudican al público.
El titular de Google News apunta a una brecha más amplia en las pruebas
La novedad importante no es una nueva prohibición federal, sino una demanda creciente de evidencia antes de que la IA llegue a flujos de trabajo de alto impacto.
El debate sobre las pruebas federales reunió a funcionarios y especialistas del Department of Homeland Security, Idaho National Laboratory y HP Federal. Sus comentarios se centraron en los sesgos, la supervisión humana y el valor de las pruebas persistentes.
Arun Vemury, asesor principal dentro de la Science and Technology Directorate de DHS, describió las pruebas como un gasto esencial pero con frecuencia descuidado. Las organizaciones suelen evitarlas porque una evaluación significativa requiere tiempo, datos adecuados, especialistas técnicos y entornos que se parezcan a las operaciones reales.
Esa omisión crea un atajo peligroso. Un modelo puede funcionar bien durante una demostración controlada y aun así fallar cuando se despliega entre poblaciones, dispositivos, ubicaciones o condiciones de trabajo diferentes.
Un sistema de reconocimiento facial ofrece un ejemplo claro. Su precisión media dice poco a quienes toman decisiones sobre su rendimiento con poca iluminación, credenciales dañadas o entre grupos demográficos. Una puntuación general impresionante puede ocultar errores concentrados que afectan a personas concretas.
Los modelos de lenguaje plantean un problema de medición distinto. Sus respuestas varían según los prompts, los documentos recuperados, las versiones del modelo y las instrucciones del sistema. Un equipo no puede establecer la fiabilidad enviando varias preguntas favorables y registrando las mejores respuestas.
Por ello, los expertos federales tratan los sesgos como algo que debe gestionarse durante toda la vida de un sistema. Este enfoque importa porque rechaza la idea de que los desarrolladores pueden eliminar toda tendencia indeseable durante el entrenamiento.
El comportamiento de un modelo surge de la selección de datos, el diseño del sistema, la interacción de los usuarios y el contexto de despliegue. Incluso un modelo técnicamente competente puede producir un resultado perjudicial cuando la tarea asignada está mal definida.
La presentación de Google News reduce este argumento a un llamado directo a realizar pruebas rigurosas. El problema completo es más difícil: las agencias necesitan programas de pruebas que reflejen cada misión, población afectada y nivel aceptable de fallo.
Ese requisito cambia quién participa en un proyecto de IA. Los responsables de compras deben pedir evidencia, los gestores de programas deben definir la tarea prevista y los expertos del área deben identificar resultados inaceptables. Los equipos de seguridad deben probar los límites de acceso, mientras que los usuarios deben evaluar si los resultados son útiles en la práctica.
Los desarrolladores por sí solos no pueden responder a esas preguntas. Entienden el sistema, pero no representan a todas las personas afectadas por sus decisiones.
La distinción entre una demostración y un despliegue es especialmente importante. Una demostración pregunta si una herramienta de IA puede producir un resultado deseado. Las pruebas de despliegue preguntan con qué frecuencia falla, qué usuarios se encuentran con esos fallos y si los controles existentes los detectan.
Las agencias federales también operan bajo restricciones que las empresas de software de consumo no siempre comparten. Sus sistemas pueden procesar historiales médicos, información sobre prestaciones, datos de las fuerzas del orden, expedientes de personal y material de seguridad nacional.
Un error inocuo en un asistente de redacción no equivale a un error en un flujo de trabajo de identidad, atención médica o elegibilidad. Las pruebas deben seguir las consecuencias, no el entusiasmo que rodea al modelo.
Por eso el titular merece atención incluso sin una nueva norma. Capta un cambio práctico: pasar de debatir principios de IA a exigir un rendimiento observable en condiciones reales.
Una adopción federal más rápida eleva lo que está en juego
Las agencias federales enfrentan presión desde ambas direcciones: avanzar demasiado despacio y perder capacidad útil, o avanzar demasiado rápido y exponer al público a sistemas poco comprendidos.
La escala de la adopción explica por qué las pruebas se han vuelto urgentes. Una revisión federal de IA de la Government Accountability Office examinó inventarios de 11 agencias.
Esos inventarios contenían 571 casos de uso de IA reportados en 2023 y 1.110 en 2024. Los casos de uso reportados de IA generativa aumentaron de 32 a 282 durante el mismo periodo, un incremento de aproximadamente nueve veces.
Estas cifras no demuestran que todos los sistemas enumerados hayan llegado a producción. Los inventarios pueden incluir usos planificados, exploratorios y operativos. Aun así, muestran que los equipos federales están evaluando la IA en muchas más tareas que antes.
Los casos de uso van más allá de los chatbots públicos. GAO identificó posibles aplicaciones en comunicación escrita, acceso a la información, seguimiento de programas, imágenes médicas y extracción de información de salud pública de documentos.
Cada categoría crea una definición distinta de rendimiento aceptable. Un asistente de redacción puede tolerar una frase torpe si una persona la revisa. Un sistema que respalda trabajo médico o de seguridad pública necesita evidencia mucho más sólida.
Por tanto, los líderes de las agencias deben clasificar el riesgo antes de elegir un plan de evaluación. La pregunta clave no es si un modelo utiliza IA generativa. Es qué ocurre cuando el modelo se equivoca.
Pensemos en una herramienta que resume políticas internas. Su riesgo más evidente es un resumen inexacto. Sin embargo, también puede omitir una excepción, exponer texto restringido, citar una norma sustituida o producir respuestas diferentes para usuarios similares.
Un piloto podría pasar por alto estos fallos porque los participantes ya entienden el material de origen. Los nuevos empleados podrían confiar en el mismo resultado sin reconocer lo que desapareció.
Las compras añaden otra capa. Las agencias suelen adquirir modelos, servicios en la nube y aplicaciones de proveedores en lugar de construirlo todo internamente. Los compradores dependen entonces de documentación y evidencia de evaluación que quizá no coincidan con el entorno gubernamental.
El benchmark de un proveedor puede establecer que un modelo funciona bien en una prueba estándar. No puede establecer que el sistema completo de una agencia se comporte de forma segura con datos locales, herramientas de recuperación, permisos y usuarios.
La distinción se vuelve más seria con la IA agéntica. Un agente de IA es un sistema que puede elegir y ejecutar acciones a través de software conectado, en lugar de limitarse a devolver texto.
Un chatbot convencional puede generar una recomendación falsa. Un agente conectado puede actuar en función de ella cambiando un registro, enviando un mensaje, llamando a un servicio externo o iniciando otro flujo de trabajo.
Las pruebas deben cubrir entonces tanto el modelo como su autoridad. Los evaluadores deben determinar qué acciones están permitidas, cómo funcionan las aprobaciones y si el sistema se detiene cuando las instrucciones entran en conflicto.
Tamara Lilly, inspectora general adjunta en el Department of Health and Human Services, ha advertido que los sistemas automatizados pueden operar más rápido que los controles tradicionales. Su orientación sobre gobernanza operativa hizo hincapié en límites claros, reglas de acceso y evidencia continua de que los controles funcionan.
Esta es la presión de fondo tras la historia de Google News. Los responsables de información y de IA deben producir resultados útiles al tiempo que evitan que la experimentación se convierta en un despliegue sin control.
La tensión presupuestaria es inevitable. Los entornos de evaluación, los conjuntos de datos representativos, los equipos rojos, las revisiones de accesibilidad, las pruebas de seguridad y la supervisión posterior al despliegue consumen recursos.
Estos gastos pueden parecer un retraso para los beneficios de la misión. Sin embargo, unas pruebas insuficientes no eliminan el coste. Trasladan ese coste a los usuarios, los equipos de respuesta a incidentes, los auditores y los futuros trabajos de subsanación.
El gobierno también enfrenta un problema de confianza del que las organizaciones privadas a veces pueden escapar. Las personas no siempre pueden elegir otro sistema de prestaciones, proceso fronterizo o agencia pública después de un fallo automatizado.
Esa falta de elección eleva el estándar. Las agencias necesitan evidencia de que una herramienta funciona para el propósito definido, no una afirmación amplia de que el modelo subyacente es avanzado.
Por ello, un programa de adopción útil separará la asistencia de bajo riesgo del apoyo a decisiones de alto impacto. Puede avanzar rápidamente en tareas de redacción reversibles y aplicar controles más estrictos a los sistemas que afectan derechos, acceso, seguridad o servicios esenciales.
Este enfoque no exige tratar todas las funciones de IA como igualmente peligrosas. Exige ajustar la evidencia y la intensidad de los controles a las consecuencias del fallo.
Velocidad frente a garantías es el verdadero conflicto de la IA federal
El conflicto central no es innovación frente a regulación; es despliegue rápido frente a garantías específicas para cada misión.
La Casa Blanca reforzó la adopción federal más rápida en abril de 2025 mediante políticas revisadas sobre el uso y la adquisición de IA por parte de las agencias. La política federal de IA hizo hincapié en reducir barreras innecesarias al tiempo que se mantienen protecciones para la privacidad, los derechos civiles y las libertades civiles.
Esta combinación parece compatible sobre el papel. En la práctica, la velocidad y las garantías compiten por el mismo personal, dinero y atención de los líderes.
Un equipo puede adquirir rápidamente un asistente comercial. No puede determinar de inmediato cómo gestiona ese asistente cada documento restringido, instrucción engañosa, afirmación sin respaldo o solicitud inusual de un usuario.
El resultado de esta disyuntiva suele presentarse de forma incorrecta. Se pregunta a los líderes si apoyan la adopción de IA o si prefieren la cautela. Ese planteamiento convierte un trabajo esencial de ingeniería en una preferencia política.
Las pruebas forman parte del despliegue, no son un argumento en su contra. La aviación, la tecnología médica, la ciberseguridad y otros ámbitos de consecuencias elevadas dependen de la evaluación porque los sistemas útiles aún pueden fallar.
La IA complica este principio porque su comportamiento es probabilístico. Un sistema probabilístico puede producir resultados diferentes a partir de entradas similares, especialmente después de que un proveedor actualice el modelo.
Las pruebas de software tradicionales siguen siendo necesarias, pero no son suficientes. Un desarrollador puede verificar que una API devuelve una respuesta sin establecer si esa respuesta es precisa, justa, segura o útil.
Los equipos federales necesitan varias capas de garantía. Las pruebas de capacidad preguntan si el sistema completa la tarea asignada. Las pruebas adversariales preguntan cómo responde a intentos de manipulación.
Las pruebas de campo examinan el rendimiento con usuarios reales y condiciones operativas realistas. La supervisión comprueba si los resultados cambian tras el despliegue, con datos nuevos o después de una actualización del modelo.
La supervisión humana conecta estas capas. Una persona no puede supervisar de forma significativa un sistema de IA sin suficiente tiempo, autoridad y conocimiento del área para cuestionar sus resultados.
Un botón de aprobación meramente nominal no crea supervisión. Si los empleados procesan cientos de recomendaciones bajo presión de plazos, pueden aceptar los resultados automáticamente.
Las agencias deben probar el flujo de trabajo humano junto con el modelo. Deben medir si los revisores detectan errores, comprenden la incertidumbre y saben cuándo escalar un resultado.
Esto genera una inversión incómoda. A menudo se adquiere IA para reducir trabajo, pero una implementación segura puede requerir inicialmente más trabajo especializado.
Los equipos de programa necesitan expertos en la materia para crear casos de prueba. Los especialistas en seguridad deben examinar los flujos de datos, los abogados deben evaluar las obligaciones legales y los expertos en accesibilidad deben valorar el impacto sobre los usuarios.
La inversión aún puede compensar. Un sistema probado puede reducir el trabajo repetitivo mientras mantiene a las personas enfocadas en las excepciones y el juicio profesional. Sin embargo, los líderes no deben fingir que la supervisión aparece automáticamente.
El mismo conflicto afecta a los proveedores. Los compradores gubernamentales quieren acceder rápidamente a modelos más nuevos, pero las actualizaciones frecuentes pueden invalidar resultados de evaluación anteriores.
Un proveedor puede mejorar el razonamiento general mientras modifica el comportamiento de rechazo, el formato o el rendimiento en una tarea especializada. Las agencias necesitan controles de versión y desencadenantes de revalidación antes de aceptar dichas actualizaciones.
Los proveedores de modelos tampoco pueden probar por sí mismos todos los contextos federales. Un sistema de propósito general enfrenta riesgos distintos cuando se conecta a registros de inmigración, datos científicos, documentos de contratación pública o flujos de trabajo clínicos.
La responsabilidad, por tanto, es compartida pero no intercambiable. Los proveedores deben divulgar limitaciones y cambios relevantes. Las agencias aún deben probar el sistema integrado en el entorno previsto.
Google News ofrece una vía sencilla para descubrir el tema, pero el conflicto de políticas va mucho más allá de un solo titular. Se pide a los líderes federales que aceleren la adopción sin rebajar los estándares asociados a la autoridad pública.
La respuesta viable es un despliegue por etapas. Los equipos comienzan con una tarea acotada, datos limitados, permisos restringidos y criterios de éxito medibles.
Luego se amplían solo cuando la evidencia respalda la expansión. Ese método conserva el impulso y crea un registro que auditores, directivos y usuarios afectados pueden examinar.
La implementación por etapas también hace que el fracaso sea más informativo. Un piloto acotado puede revelar que un modelo no es adecuado sin generar un problema de servicio a escala nacional.
La alternativa es desplegar por entusiasmo. Ese camino trata la fluidez inicial como prueba, confunde los benchmarks de proveedores con el rendimiento de la misión y descubre las limitaciones mediante incidentes públicos.
Las pruebas rigurosas de IA deben acompañar al sistema hasta producción
Una prueba previa al despliegue es un punto de partida, porque el comportamiento de la IA puede cambiar cuando cambian los modelos, los datos, los usuarios y las herramientas conectadas.
El National Institute of Standards and Technology describe las pruebas mediante el proceso más amplio de pruebas, evaluación, verificación y validación. Este proceso suele abreviarse como TEVV.
El marco de riesgos de NIST indica que los sistemas de IA deben probarse antes de su despliegue y periódicamente durante su operación. También exige métodos documentados, criterios medibles, condiciones realistas y participación de expertos independientes o internos ajenos al equipo de desarrollo.
Esa orientación revela por qué importa la palabra «rigurosas». Someter un modelo una vez a una lista fija de prompts no demuestra un rendimiento confiable.
Una evaluación significativa comienza con una tarea definida. Las agencias deben especificar los usuarios previstos, los datos disponibles, las condiciones operativas, las acciones prohibidas y las consecuencias del fallo.
Los evaluadores pueden entonces construir pruebas en torno a casos realistas. Deben incluir ejemplos ordinarios, casos poco frecuentes, entradas adversarias, información incompleta y situaciones en las que el sistema debería negarse a actuar.
Las métricas también deben reflejar la misión. La precisión puede importar, pero quizá no capture si los errores se concentran en determinados grupos.
Un equipo que evalúa resúmenes podría medir afirmaciones sin respaldo, requisitos omitidos, citas incorrectas y divulgación de información restringida. Un equipo que evalúa tecnología de identidad necesitaría medidas diferentes.
Los umbrales deben establecerse antes de que los líderes vean resultados favorables. De lo contrario, los equipos de proyecto pueden redefinir el éxito después de observar las debilidades del sistema.
La evaluación independiente ayuda a abordar ese riesgo. Los desarrolladores comprenden naturalmente cómo obtener buenos resultados de su sistema. Los usuarios y evaluadores externos tienen más probabilidades de descubrir instrucciones confusas y comportamientos inesperados.
El red teaming aporta otra perspectiva. El red teaming son pruebas adversarias estructuradas que buscan debilidades, resultados perjudiciales o formas de eludir controles.
No debería convertirse en teatro. Unos pocos prompts llamativos pueden generar publicidad sin medir los riesgos que importan para una agencia concreta.
Los buenos equipos de red teaming trabajan a partir de un modelo de amenazas, que identifica posibles atacantes, activos protegidos, métodos probables y consecuencias operativas. Sus hallazgos deben conducir a correcciones, nuevas pruebas y decisiones documentadas.
Las pruebas de campo son igual de importantes porque los laboratorios no pueden reproducir todo comportamiento humano. Los empleados pueden copiar documentos más extensos de lo esperado, formular preguntas ambiguas o combinar resultados con información no oficial.
Un sistema también puede cambiar el entorno laboral que lo rodea. El personal puede dejar de verificar fuentes primarias, modificar cómo documenta las decisiones o depender de lenguaje generado que oscurece la rendición de cuentas.
Esos efectos rara vez aparecen en un benchmark. Surgen mediante observación, entrevistas con usuarios, informes de incidentes y mediciones repetidas.
La supervisión en producción debe detectar entonces la deriva. La deriva significa que la relación entre las entradas, el comportamiento del modelo y los resultados esperados cambia con el tiempo.
La causa puede ser una nueva versión del modelo, una población de usuarios diferente, una colección de recuperación modificada o cambios en las condiciones del mundo real. Cualquiera de estos factores puede debilitar una evaluación anterior.
La supervisión debe registrar más que la disponibilidad del sistema. Los equipos necesitan señales sobre resultados inusuales, controles fallidos, anulaciones por usuarios, quejas y calidad específica de la tarea.
También necesitan un proceso para incidentes. Los empleados deben saber dónde informar un resultado sospechoso, y los responsables del programa deben tener autoridad para restringir o suspender el sistema.
Esa capacidad importa aún más para los agentes conectados. El acceso de mínimo privilegio significa otorgar a un sistema solo los permisos necesarios para su tarea asignada.
Un asistente de redacción no necesita autoridad para publicar. Un agente de programación no necesita acceso sin restricciones a los registros de personal.
Los equipos deben probar qué ocurre cuando el modelo solicita una acción fuera de sus permisos. El resultado esperado debe ser un fallo controlado, no una solución improvisada.
La evaluación de datos merece la misma atención. Las agencias necesitan comprender qué información entra en un modelo, dónde se procesa, qué se conserva y quién puede recuperarla.
La generación aumentada por recuperación, un método que proporciona documentos seleccionados a un modelo, puede mejorar la relevancia. También puede reproducir material desactualizado, no autorizado o contradictorio.
Por ello, la gobernanza documental pasa a formar parte de las pruebas de IA. Una base de conocimiento consultable confiable necesita propiedad definida, controles de acceso, material fuente actualizado y actualizaciones trazables.
El punto escéptico es que ningún programa de evaluación puede demostrar que un modelo general sea seguro en todas las condiciones. Las posibles entradas e interacciones son demasiado amplias.
Las agencias deben evitar afirmaciones absolutas como imparcial, seguro o libre de alucinaciones. Esas descripciones exceden lo que una prueba acotada puede establecer.
Una conclusión defendible es más limitada. La evidencia puede demostrar que un sistema concreto cumplió umbrales definidos para una tarea, versión, población y entorno determinados.
Esa salvedad no es una debilidad. Es la base de una garantía honesta.
Los equipos federales también deben publicar suficiente información para permitir la supervisión sin exponer sistemas sensibles. Pueden describir el uso previsto, las categorías de evaluación, las limitaciones y los procesos de supervisión mientras protegen los detalles operativos.
La transparencia fortalece la rendición de cuentas porque permite al público distinguir entre un asistente controlado y un tomador de decisiones automatizado. También ofrece a inspectores y legisladores una base para formular preguntas precisas.
El mayor riesgo de implementación es convertir las pruebas en una lista de verificación. Un formulario completado no puede sustituir evidencia realista.
Los documentos de cumplimiento importan, pero deben remitir a resultados de pruebas, registros de incidentes, versiones de modelos y responsables identificables. De lo contrario, las agencias corren el riesgo de producir una amplia documentación en torno a un sistema incierto.
Qué deberían vigilar los compradores federales de IA a continuación
La próxima fase se medirá por si las agencias federales convierten los principios de prueba en puertas de despliegue exigibles y evidencia continua.
La primera señal es cómo implementan las agencias la aprobación basada en riesgos para la IA con consecuencias significativas. Los inventarios por sí solos no pueden mostrar si los líderes detuvieron, limitaron o rediseñaron sistemas que no superaron la evaluación.
Esté atento a documentación pública que distinga la asistencia de bajo riesgo de la IA que afecta derechos, seguridad, acceso o servicios esenciales. Las categorías claras reforzarían el argumento de que una adopción más rápida puede coexistir con una garantía más estricta.
La ausencia de esas categorías lo debilitaría. Las agencias podrían afirmar cumplimiento mientras aplican revisiones similares a riesgos fundamentalmente distintos.
La segunda señal es si los contratos de contratación preservan los derechos de evaluación después de la compra. Los compradores gubernamentales necesitan acceso a avisos de cambios en los modelos, documentación relevante, apoyo para pruebas y controles sobre las actualizaciones.
El lenguaje contractual también debe aclarar las responsabilidades ante incidentes y el manejo de datos. Sin esos términos, las agencias pueden quedar dependientes de garantías de proveedores que no reflejan su entorno desplegado.
La evidencia de requisitos contractuales repetibles mostraría que las pruebas han avanzado hacia la fase de adquisición. La dependencia continuada de afirmaciones genéricas sobre rendimiento sugeriría que la brecha de despliegue persiste.
La tercera señal es lo que las agencias informan después de que los sistemas llegan a producción. La evidencia útil incluiría prácticas de supervisión, incidentes significativos, acciones correctivas y ejemplos de usos restringidos o discontinuados.
La falta de incidentes reportados no demuestra necesariamente seguridad. Puede indicar que los empleados carecen de canales de denuncia o que las agencias definen los incidentes de forma demasiado limitada.
Los lectores deberían prestar especial atención a los sistemas que obtienen permiso para actuar. El paso de texto generado a acción autónoma aumenta tanto el beneficio potencial como el coste de un error.
Aquí es donde Google News y plataformas de descubrimiento similares tienen un papel útil. Pueden sacar a la luz audiencias de agencias, entrevistas con especialistas, informes de organismos de vigilancia y cambios de políticas que, de otro modo, permanecerían dispersos.
Sin embargo, la agregación no es verificación. Los lectores deben seguir un titular hasta la información original y luego comparar sus afirmaciones con políticas, auditorías y orientación técnica.
La evidencia actual respalda una conclusión prudente. El despliegue federal de IA se está ampliando, mientras los expertos aún desarrollan los métodos necesarios para evaluar sistemas en condiciones realistas.
Eso no justifica congelar todos los proyectos. Respaldan casos de uso acotados, umbrales medibles, autoridad humana, permisos restringidos y supervisión después del lanzamiento.
La pregunta decisiva ya no es si las agencias federales utilizarán IA. Ya lo hacen, y sus casos de uso reportados han crecido de manera sustancial.
La pregunta es si cada agencia puede demostrar por qué un sistema específico merece la autoridad asignada. Esa prueba debe incluir la tarea, las condiciones probadas, los umbrales de fallo, el responsable y la respuesta cuando cambia el comportamiento.
Cuando el próximo titular de Google News anuncie una implementación federal de IA, mire más allá del nombre del modelo. Pregunte qué se probó, quién lo evaluó, qué fallos persisten y si la agencia puede detener el sistema de forma segura.
