No basta con que una organización publique una política de uso responsable de la inteligencia artificial y luego suponga que la conducta se ajustará a ella. Los desarrolladores trabajan bajo presión para entregar resultados y se enfrentan a problemas poco claros, por lo que pueden recurrir a herramientas no autorizadas cuando el canal oficial parece lento o desconectado de los detalles del trabajo de ingeniería. De ahí que el artículo publicado en Stack Overflow Blog plantee una idea central: limitar la «inteligencia artificial oculta» comienza con el diseño del flujo de trabajo, no con añadir otro documento al portal de aprendizaje.
El material se basa en los resultados de Stack Overflow sobre la adopción de la inteligencia artificial y la confianza de los desarrolladores; el 84% de los participantes afirmó que utiliza herramientas de inteligencia artificial o planea utilizarlas, mientras que el número de desarrolladores que no confían en la precisión de estas herramientas supera al de quienes sí confían en ella. Los resultados que parecen correctos aproximadamente y luego requieren correcciones adicionales fueron una de las principales fuentes de frustración.
El uso no autorizado es una señal de un fallo en el flujo de trabajo
El artículo propone que la dirección no trate cada uso no autorizado como una infracción de cumplimiento plenamente constituida. Cuando un ingeniero copia material sensible en un modelo público o instala un asistente de programación no autorizado, puede ser una señal de que el proceso aprobado no proporciona los datos, el contexto, las integraciones o los permisos necesarios para completar la tarea.
La respuesta práctica comienza con preguntas de diagnóstico: ¿qué tareas llevan a los desarrolladores a utilizar herramientas externas? ¿Qué fricción dificulta la alternativa aprobada? ¿Es posible ofrecer experimentación mediante plataformas aprobadas y puertas de control que registren el uso, en lugar de intentar impedirlo mediante un bloqueo generalizado? Desde esta perspectiva, el uso informal se convierte en una evidencia que ayuda a la organización a mejorar el sistema, no en un motivo automático para obligar a los empleados a ocultar sus experimentos.
Convertir la política en una interfaz de ingeniería
Una buena política define el propósito, pero una buena operación lo traduce en decisiones que el desarrollador puede tomar durante el trabajo diario. El artículo señala las funciones del marco de NIST para la gestión de riesgos de la inteligencia artificial: gobernanza, identificación, medición y gestión. En la práctica, las reglas deberían aclarar cómo clasificar un caso de uso, qué modelos y fuentes de datos están permitidos, cómo probar los resultados, qué parte es responsable de la aprobación y qué evidencias deben conservarse en el registro de desarrollo.
Entre las preguntas que la política debería responder directamente se encuentran: ¿qué datos pueden introducirse en cada herramienta? ¿A qué repositorios o sistemas se permite acceder a la herramienta? ¿Qué nivel de revisión requiere el código generado? ¿Cuándo es necesaria la intervención de un responsable humano? ¿Cómo informa el desarrollador sobre resultados dañinos, inseguros o poco fiables? ¿Cuándo se convierte la experimentación en un sistema de producción? El artículo señala que la seguridad y la privacidad son algunas de las principales razones por las que los desarrolladores rechazan las tecnologías, lo que convierte las reglas claras en un factor que favorece la adopción cuando reducen la ambigüedad.
Colocar los controles donde tiene lugar el trabajo
Una política guardada en un portal de capacitación difícilmente puede competir con un asistente integrado en el entorno de desarrollo integrado. Por ello, el artículo propone colocar los controles en los repositorios, las solicitudes de incorporación de cambios, las canalizaciones de compilación, los sistemas de acceso y los flujos de trabajo de despliegue. Algunos ejemplos son guardar la configuración de los modelos aprobados en un sistema de control de versiones, restringir el acceso según el rol, examinar las indicaciones y los resultados en busca de secretos, conservar registros en los casos de uso de mayor riesgo y exigir pruebas antes de integrar los cambios generados.
Asimismo, la frase «revisa los resultados de la inteligencia artificial» debería transformarse en pasos repetibles, como comprobaciones funcionales, verificación de la adecuación al contexto, revisión de dependencias y revisión colectiva cuando sea necesario. Un único nivel de aprobación no es adecuado para todos los usos; una herramienta que explica código tiene riesgos diferentes de los de un agente con permiso para escribir en sistemas de producción. El artículo menciona riesgos de la lista de OWASP para aplicaciones de inteligencia artificial generativa, entre ellos la inyección de indicaciones, la exposición de información sensible, las debilidades de la cadena de suministro, el manejo inadecuado de los resultados y los permisos excesivos.
Responsabilidad, capacitación y medición
Debería designarse un responsable humano claro para cada caso de uso, que comprenda el resultado deseado y tenga autoridad para detener o modificar el proceso. Según la división propuesta, los responsables de producto asumen la decisión comercial; los responsables de ingeniería, la calidad de la ejecución; los especialistas en seguridad y privacidad, la definición de los controles adecuados; los desarrolladores, la responsabilidad del código que entregan; los revisores, la decisión de aprobarlo; y los operadores, la supervisión y la respuesta ante incidentes.
El artículo también aboga por una capacitación vinculada a las decisiones reales de los desarrolladores, no por una sesión general de concienciación. Esto incluye las herramientas aprobadas, los datos permitidos, los patrones de fallo, los requisitos de revisión, la vía de escalamiento y ejemplos del entorno de la organización. La capacitación debería producir elementos utilizables dentro del flujo de trabajo, como instrucciones para repositorios, listas de comprobación, conjuntos de pruebas, patrones de indicaciones aprobados y ejemplos documentados; el certificado demuestra la asistencia, pero son estos elementos los que influyen en la conducta.
La medición del éxito tampoco debería limitarse al número de licencias, indicaciones o usuarios activos. El artículo propone comparar el flujo de trabajo antes y después de introducir la herramienta mediante indicadores como el tiempo de ciclo, los defectos que llegan a producción, las operaciones de reversión, los resultados de las revisiones de seguridad, la carga de revisión, la calidad de la documentación, los incidentes, la satisfacción de los desarrolladores y el tiempo dedicado a corregir los resultados. Este punto merece especial atención porque los resultados de DORA de 2024 relacionaron una mayor adopción con una mejora de la calidad de la documentación y del código y con una mayor velocidad de revisión, pero también detectaron posibles efectos negativos en el rendimiento de la entrega de software. La encuesta de Stack Overflow también señaló posibles beneficios individuales con los agentes, sin beneficios equivalentes en la colaboración grupal.
La lectura editorial de certi.news
El cambio real que propone el material no está en redactar una nueva política, sino en trasladar la responsabilidad del nivel de los documentos al nivel de las herramientas y los procesos. El proceso seguro se vuelve utilizable cuando ofrece herramientas aprobadas, contexto útil, límites claros, un escalamiento rápido y controles proporcionales a la sensibilidad de los datos, el grado de autonomía y la reversibilidad del impacto.
Esto no es una receta para eliminar el juicio humano, sino un intento de convertirlo en una parte visible del ciclo de desarrollo. La eficacia de las propuestas sigue estando vinculada a la capacidad de cada organización para definir los casos de uso y medir sus resultados reales; además, las cifras incluidas en el artículo resumen los resultados de varios estudios y encuestas y, por sí solas, no demuestran que todos los entornos de desarrollo obtendrán el mismo resultado.