14.1 Introducción
Una IA puede proponer código, modificar archivos y ejecutar pruebas. Sin embargo, no conoce por sí sola todas las obligaciones de una organización ni asume las consecuencias cuando una aplicación falla, expone datos o perjudica a sus usuarios.
La responsabilidad permanece en las personas que definen el objetivo, autorizan el uso de la herramienta, revisan el resultado y deciden publicarlo. Esta responsabilidad no exige realizar manualmente cada línea, pero sí aplicar una supervisión proporcional al riesgo.
El desarrollador actúa como responsable técnico de decisiones que afectan a otras personas. Debe poder explicar qué se cambió, por qué se eligió esa solución y qué evidencia permite confiar en ella.
14.2 Responsabilidad a lo largo del proceso
La responsabilidad no comienza al publicar. Aparece desde el momento en que elegimos una tarea y proporcionamos información a la herramienta.
| Etapa | Decisión humana | Evidencia esperada |
|---|---|---|
| Definición | Establecer objetivo, alcance y restricciones. | Requisitos y criterios de aceptación. |
| Contexto | Decidir qué datos y archivos pueden compartirse. | Políticas y clasificación de la información. |
| Generación | Controlar permisos, herramientas y acciones. | Registro de cambios y comandos. |
| Revisión | Evaluar corrección, calidad y riesgos. | Diferencias, pruebas y revisión técnica. |
| Publicación | Autorizar el cambio y preparar reversión. | Aprobación, respaldo y plan de despliegue. |
| Mantenimiento | Observar, corregir y actualizar. | Monitoreo, incidentes y documentación vigente. |
14.3 Definir con claridad qué se intenta resolver
Una solicitud imprecisa puede producir un resultado técnicamente elaborado que resuelve el problema equivocado. Es responsabilidad del desarrollador transformar necesidades generales en comportamientos verificables.
Antes de pedir código conviene identificar:
- Quién necesita la función y para qué.
- Qué entradas recibe y de dónde provienen.
- Qué resultado debe producir.
- Qué situaciones de error deben contemplarse.
- Qué datos, permisos y servicios intervienen.
- Qué comportamientos existentes no deben cambiar.
Si existen decisiones de producto todavía abiertas, deben resolverse con las personas involucradas. La IA puede proponer alternativas, pero no conoce cuál representa mejor sus necesidades.
14.4 Revisar el código generado
Aceptar una modificación implica asumirla como parte del proyecto. La revisión debe incluir todas las diferencias, no solamente el archivo principal o la explicación final de la IA.
Una revisión responsable comprueba:
- Que cada cambio se relacione con el objetivo.
- Que no se hayan eliminado comportamientos necesarios.
- Que las API y dependencias utilizadas existan.
- Que entradas, errores y casos límite estén tratados.
- Que el código respete la arquitectura y convenciones.
- Que los comentarios describan el comportamiento real.
Si no comprendemos una sección, debemos investigarla, pedir una explicación verificable o solicitar revisión a alguien con experiencia antes de incorporarla.
14.5 Verificar mediante pruebas y observación
La revisión visual detecta muchos problemas, pero no reemplaza la ejecución. También debemos comprobar el resultado en un entorno adecuado.
| Comprobación | Responsabilidad |
|---|---|
| Formateo y análisis estático | Aplicar las reglas automáticas del proyecto. |
| Pruebas automatizadas | Ejecutar las existentes y agregar casos necesarios. |
| Prueba manual | Recorrer el flujo como una persona usuaria. |
| Integración | Confirmar contratos con datos y servicios reales o equivalentes. |
| Seguridad | Evaluar entradas, permisos, secretos y exposición. |
| Monitoreo | Observar el comportamiento después de publicar. |
Si una herramienta afirma que las pruebas pasan, debemos confirmar que realmente fueron ejecutadas, cuáles se ejecutaron y qué alcance tienen.
14.6 Proteger la privacidad y los secretos
El desarrollador decide qué información se envía a la herramienta. Esa decisión debe respetar políticas, contratos y obligaciones sobre datos.
No debemos compartir sin autorización:
- Contraseñas, tokens y claves privadas.
- Datos personales de clientes o empleados.
- Registros que contengan sesiones o identificadores.
- Código sujeto a restricciones de confidencialidad.
- Información interna de infraestructura.
- Documentos comerciales o legales reservados.
Cuando sea posible utilizaremos valores ficticios, datos anonimizados y ejemplos mínimos. También debemos conocer cómo el servicio conserva la información, qué controles ofrece y si su uso fue aprobado por la organización.
14.7 Construir software seguro
La IA puede sugerir controles, pero el desarrollador debe comprender qué amenaza intenta reducir cada uno. Una validación genérica no protege todos los contextos.
Entre las responsabilidades básicas se encuentran:
- Validar datos en el límite donde ingresan al sistema.
- Aplicar autorización en cada operación protegida.
- Conceder únicamente los permisos necesarios.
- Conservar secretos fuera del código fuente.
- Evitar datos sensibles en errores y registros.
- Actualizar y revisar las dependencias.
- Diseñar una respuesta para incidentes.
Los cambios relacionados con autenticación, pagos, criptografía o permisos requieren una revisión especialmente rigurosa y, cuando corresponda, intervención especializada.
14.8 Considerar accesibilidad e inclusión
Una interfaz generada puede verse atractiva y al mismo tiempo excluir a personas que navegan con teclado, lectores de pantalla, ampliación o diferentes capacidades perceptivas.
El desarrollador debe comprobar:
- Estructura semántica de títulos, controles y regiones.
- Etiquetas asociadas a campos de formulario.
- Navegación completa mediante teclado.
- Foco visible y orden comprensible.
- Contraste suficiente y contenido que no dependa solo del color.
- Mensajes de error claros y asociados al campo correspondiente.
- Adaptación a tamaños de pantalla y ampliación.
Las herramientas automáticas ayudan a detectar algunos errores, pero la prueba con tecnologías de asistencia y personas reales aporta evidencia que una captura visual no ofrece.
14.9 Dependencias, licencias y procedencia
Una propuesta puede agregar paquetes para resolver rápidamente una función. Cada dependencia incorpora código externo, actualizaciones, posibles vulnerabilidades y condiciones de licencia.
Antes de aceptarla debemos verificar:
- Que el paquete exista en el registro oficial.
- Que el nombre y el autor sean los esperados.
- Que tenga mantenimiento y uso razonables.
- Que su licencia sea compatible con el proyecto.
- Que no duplique una capacidad ya disponible.
- Que la versión elegida sea compatible y segura.
También es responsabilidad del equipo seguir las políticas aplicables sobre código generado y propiedad intelectual. Ante una duda legal, se consultan fuentes y profesionales adecuados; no se utiliza la respuesta de un modelo como autorización.
14.10 Evitar decisiones injustas o discriminatorias
El software puede clasificar, priorizar o recomendar acciones que afectan a personas. Los datos históricos y los criterios elegidos pueden reproducir desigualdades aunque el código funcione según su especificación.
Si una función interviene en selección, crédito, educación, salud u otros ámbitos sensibles debemos preguntar:
- Qué decisión automatiza o influye.
- Qué variables utiliza y por qué.
- Qué grupos pueden verse perjudicados.
- Cómo puede una persona comprender o cuestionar el resultado.
- Qué revisión humana existe.
- Cómo se medirá el impacto real.
Delegar a una IA la implementación no elimina la necesidad de analizar la finalidad y las consecuencias del sistema.
14.11 Transparencia y trazabilidad
Un equipo necesita reconstruir por qué se realizó una modificación. La trazabilidad permite relacionar necesidad, decisión, código y evidencia.
| Elemento | Qué debería registrar |
|---|---|
| Requisito | Problema y comportamiento esperado. |
| Decisión | Alternativas consideradas y motivo de elección. |
| Cambio | Archivos y comportamiento modificados. |
| Prueba | Casos ejecutados y resultados obtenidos. |
| Limitación | Aspectos no cubiertos o riesgos aceptados. |
| Aprobación | Quién revisó y autorizó la publicación. |
No siempre es necesario conservar toda la conversación con la IA. Sí conviene registrar las decisiones relevantes en los mecanismos habituales del proyecto.
14.12 Colaborar sin ocultar el origen del trabajo
En un equipo, presentar código generado como si estuviera completamente comprendido dificulta la revisión. La comunicación honesta permite concentrar atención donde existe mayor incertidumbre.
Un resumen responsable puede indicar:
- Qué parte fue producida con asistencia.
- Qué archivos fueron revisados personalmente.
- Qué pruebas se ejecutaron.
- Qué decisiones siguen abiertas.
- Qué secciones necesitan una revisión especializada.
El objetivo no es etiquetar cada línea, sino evitar una confianza falsa y facilitar que otras personas puedan evaluar el cambio.
14.13 Publicación, reversión y monitoreo
Una prueba exitosa en el entorno local no garantiza el comportamiento en producción. La publicación debe contemplar qué ocurrirá si aparece un problema.
Antes de desplegar conviene definir:
- Qué versión exacta se publicará.
- Qué configuración y migraciones necesita.
- Cómo se comprobará inmediatamente el funcionamiento.
- Qué métricas y errores se observarán.
- Qué condición obliga a detener o revertir.
- Cómo se recuperan código y datos.
- Quién puede tomar cada decisión.
La responsabilidad continúa después del despliegue. Los problemas observados deben investigarse y convertirse en correcciones, pruebas o mejoras del proceso.
14.14 Responder ante errores e incidentes
Incluso con controles, el software puede fallar. Una respuesta responsable busca limitar el daño, comprender el alcance y evitar la repetición.
Ante un incidente corresponde:
- Proteger a las personas y datos afectados.
- Detener o aislar el comportamiento peligroso.
- Conservar evidencia útil para investigar.
- Comunicar por los canales definidos.
- Corregir la causa, no solamente el síntoma visible.
- Agregar pruebas y controles preventivos.
- Documentar lo aprendido sin reducir el análisis a culpar a una persona o herramienta.
Ocultar un error porque fue generado por IA retrasa la recuperación. Informarlo temprano permite reducir su impacto.
14.15 Lista de comprobación responsable
Antes de considerar terminado un cambio asistido por IA podemos revisar:
- ¿El objetivo y los criterios de aceptación están claros?
- ¿La información compartida estaba autorizada?
- ¿Comprendemos todos los archivos modificados?
- ¿Confirmamos dependencias y API desconocidas?
- ¿Probamos casos normales, límites y errores?
- ¿Revisamos seguridad, privacidad y accesibilidad?
- ¿El cambio respeta licencias y políticas?
- ¿Existe documentación suficiente para mantenerlo?
- ¿Podemos revertirlo y observarlo después de publicar?
- ¿La revisión fue proporcional a sus consecuencias?
La lista no sustituye el criterio, pero evita que la velocidad de generación deje controles importantes fuera del proceso.
14.16 Actividad de comprensión
Una IA generó para una tienda un formulario de registro, una base de datos de clientes y el envío automático de correos promocionales. La demostración funciona y el equipo quiere publicarla al día siguiente.
- Identificá qué requisitos y consentimientos deberían confirmarse.
- Enumerá los datos personales involucrados y cómo deberían protegerse.
- Proponé pruebas funcionales, de seguridad y accesibilidad.
- Indicá qué dependencias y servicios externos revisarías.
- Definí qué documentación debe quedar registrada.
- Prepará un plan de publicación, monitoreo y reversión.
- Explicá quién debería aprobar cada aspecto y por qué.
Finalmente, redactá un informe breve que diferencie lo comprobado, lo pendiente y las razones por las que el prototipo todavía puede o no considerarse listo para producción.