Lista de verificación de responsabilidad de la IA inspirada en Timnit Gebru: documenta datos, limitaciones y posibles daños para usuarios para decidir si una función debe lanzarse.
Construir una función de IA solía ser sobre todo una pregunta técnica: ¿podemos hacer que el modelo funcione? Ahora la pregunta más difícil es si deberías desplegarla y qué límites necesitas.
Una vez que usuarios reales dependen de la salida de la IA, pequeños problemas se convierten en costes reales: decisiones erróneas, clientes confundidos, fugas de privacidad o trato injusto.
La responsabilidad de la IA no es una vibra ni una promesa. Es documentación escrita más decisiones claras que alguien posee. Si no puedes señalar qué datos usaste, qué no puede hacer el sistema y qué harás cuando falle, no tienes responsabilidad. Tienes esperanza.
Esto importa sobre todo justo antes del lanzamiento, cuando es tentador tratar la documentación como opcional. Lanzar sin ella crea sorpresas costosas después: tickets de soporte sin respuesta, usuarios enfadados, retrocesos de producto y señalamientos internos.
Una lista de verificación simple obliga a respuestas concretas:
El objetivo no es teoría. Es documentar lo básico (datos, límites, riesgos) y luego tomar una decisión que puedas defender después, incluso si te mueves rápido.
Timnit Gebru es una de las voces más citadas en responsabilidad de IA porque impulsó una idea simple que muchos equipos omitían: no basta con preguntar "¿podemos construirlo?" También hay que preguntar "¿debemos desplegarlo, a quién podría perjudicar y cómo lo sabríamos?"
Una parte importante de ese cambio es hacer los sistemas de IA legibles para otras personas. No solo para los ingenieros que entrenaron el modelo, sino para revisores, gestores de producto, equipos de soporte y usuarios. La idea es escribir lo que el sistema pretende hacer, qué datos lo moldearon, dónde falla y cómo se ven los riesgos en la vida real.
Dos artefactos prácticos se hicieron populares porque hacen esa legibilidad concreta:
Para los equipos de producto, esto no es papeleo por sí mismo. La documentación es evidencia. Cuando alguien pregunte "¿Por qué lanzamos esta función?" o "¿Por qué no detectaste este modo de fallo?" necesitas algo que puedas señalar: qué mediste, qué decidiste no soportar y qué salvaguardas añadiste.
Un ejemplo concreto: si añades un botón de resumen por IA en una herramienta de soporte, las notas del modelo deberían decir si se probó en temas sensibles, cómo maneja la incertidumbre y cuál es el paso de revisión humana. Eso convierte una preocupación vaga en una decisión que puedes defender y mejorar.
Una función de IA es cualquier parte de un producto donde la salida de un modelo puede cambiar lo que la gente ve, lo que puede hacer o cómo es tratada. Si la salida influye en una decisión, incluso una pequeña, trátala como una función real con consecuencias reales.
Tipos comunes incluyen resumen, clasificación, recomendaciones, moderación y puntuación (riesgo, fraude, calidad, elegibilidad, prioridad).
Cuando las cosas van mal, el impacto puede llegar más allá de la persona que hace clic. Las personas que pueden resultar perjudicadas incluyen usuarios finales, no usuarios (personas mencionadas o perfiladas), personal de soporte y moderadores, contratistas y revisores, y sujetos de datos cuyos datos se usaron para entrenar o evaluar la función.
Ayuda separar errores de daños. Un error es que el modelo esté equivocado: un mal resumen, una bandera falsa o una recomendación irrelevante. El daño es lo que ese error causa en el mundo real: pérdida de dinero, acceso injusto, reputación dañada o riesgos de seguridad. Por ejemplo, un asistente de soporte que alucina una política de reembolsos es un error. El daño es un cliente tomando una decisión basada en ello y luego siendo denegado, o un agente de soporte teniendo que manejar tickets enojados.
Los daños suelen ser desiguales entre grupos y contextos. Un modelo de moderación podría “funcionar bien” para la mayoría pero interpretar mal jerga o dialecto, provocando más eliminaciones para una comunidad. Un modelo de ranking podría ocultar a vendedores pequeños a menos que coincidan con patrones comunes en marcas grandes.
Si construyes funciones de IA mediante un creador guiado por chat como Koder.ai, la velocidad es real, pero el trabajo de responsabilidad sigue siendo el mismo. Aún necesitas ser claro sobre dónde puede fallar el modelo y quién paga el precio cuando lo hace.
Antes de lanzar una función de IA, necesitas un pequeño conjunto de documentos que respondan a una pregunta: ¿qué construimos, para quién y qué puede salir mal? Manténlo corto, pero haz que cada afirmación sea comprobable.
Conjunto mínimo por escrito antes del lanzamiento:
"Documentado" no es lo mismo que "entendido." Un documento que nadie lee es solo un archivo. Haz que una persona fuera del equipo de desarrollo lo lea y firme en lenguaje claro: "Entiendo los límites y el impacto en usuarios." Si no pueden resumirlo, no estás listo.
Asigna un único responsable para mantener los docs actualizados (usualmente el propietario del producto, no legal). Fija una cadencia (en cada release o cada mes), más una actualización inmediata tras cualquier incidente.
Mantén el tono honesto y concreto. Evita afirmaciones como "alta precisión" a menos que nombres el conjunto de prueba, la métrica y los casos de fallo que no arreglaste.
Buenas notas de datos hacen dos trabajos: te ayudan a predecir fallos antes de que los usuarios los encuentren, y dan a futuros compañeros una razón clara para confiar (o dejar de confiar) en el sistema.
Mantén el nivel de detalle “suficiente para responder preguntas difíciles en 10 minutos.” No estás escribiendo una tesis. Estás anotando hechos que alguien necesitará durante un informe de bug, una revisión de privacidad o una queja de cliente.
Empieza con un inventario simple de datos. Para cada conjunto (incluyendo logs, feedback y fuentes de terceros), registra la fuente y quién la controla, cuándo se recopiló y con qué frecuencia se actualiza, qué comportamiento de producto soporta, qué límites de privacidad y consentimiento aplican, y cómo se etiquetó o limpió.
La representatividad merece su propia línea. Nombra lo que falta: regiones, idiomas, dispositivos, necesidades de accesibilidad, tipos de usuarios o casos límite. Escríbelo claramente, como "principalmente usuarios móviles en inglés de EE. UU." o "pocos ejemplos de pequeñas empresas."
Si usas etiquetas humanas, documenta el contexto de los etiquetadores (expertos vs. crowd), las instrucciones que vieron y dónde estuvieron en desacuerdo. El desacuerdo no es un defecto para ocultar. Es una señal de advertencia para diseñar en torno a ello.
Los docs de limitaciones son donde pasas de "funcionó en la demo" a "esto es lo que esta función puede manejar con seguridad." Si solo escribes el camino feliz, los usuarios encontrarán los bordes por ti.
Empieza nombrando el trabajo del modelo en una frase, luego di para qué no sirve. "Redactar respuestas cortas a preguntas comunes" es muy diferente de "decidir reembolsos" o "detectar fraude." Ese límite facilita decisiones posteriores (texto de la UI, reglas de escalado, formación de soporte).
Captura patrones de fallo conocidos en lenguaje llano. Una buena sección de límites suele cubrir qué entradas lo confunden (peticiones ambiguas, contexto faltante, idiomas mezclados), qué tono interpreta mal (sarcasmo, bromas, enfado), qué hace mal en casos raros (términos nicho, productos inusuales) y qué puede romperlo a propósito (prompt injection, cebos para revelar datos privados).
Incluye restricciones operativas porque cambian la experiencia y la seguridad. Anota objetivos de latencia, límites de coste y qué ocurre cuando se alcanzan (timeouts, respuestas más cortas, menos reintentos). Señala límites de ventana de contexto (puede olvidar mensajes anteriores) y cambios de dependencia (cambiar de proveedor de LLM o actualizar un modelo puede modificar el comportamiento).
Luego produce una única advertencia que puedas reutilizar en el producto:
"Las respuestas generadas por IA pueden estar incompletas o ser erróneas. No las use para decisiones legales, médicas o financieras. Si esto afecta facturación, reembolsos o acceso a la cuenta, contacte con soporte."
Actualiza esta nota cada vez que el modelo, los prompts o las políticas cambien.
Una evaluación de daños no es un debate sobre ética abstracta. Es un documento corto que dice: si esta función falla, quién puede resultar perjudicado, cómo, y qué haremos antes y después del lanzamiento.
Empieza con categorías amplias para no perder lo obvio: seguridad, discriminación, privacidad, engaño y fiabilidad.
Luego convierte cada daño en una situación real. Escribe una o dos historias concretas por categoría: quién es el usuario, qué pregunta, qué podría devolver el modelo y qué podría hacer el usuario a continuación. La clave es la cadena de acción. Una respuesta errónea es molesta. Una respuesta errónea que desencadena una decisión médica, una transferencia de dinero o un cambio de política es mucho mayor.
Para priorizar, usa escalas simples. Para cada escenario, marca severidad (baja, media, alta) y probabilidad (baja, media, alta). No necesitas números perfectos. Necesitas una vista compartida de qué merece trabajo ahora.
Finalmente, asigna responsables. Una mitigación sin nombre no es una mitigación. Para cada escenario, escribe la mitigación antes del lanzamiento (salvaguardas, UX, temas bloqueados, registro), la mitigación después del lanzamiento (guion de soporte, monitoreo, disparador de rollback) y quién es responsable.
Gating es cómo pasas de "podemos construirlo" a "debemos lanzarlo." Trátalo como un conjunto de salidas: no pasas la siguiente hasta que lo básico esté documentado, revisado y probado.
Escribe la intención y la decisión que influirá. Sé específico sobre quién lo usa, qué deciden y qué pasa si la salida está mal.
Redacta tus notas de datos y limitaciones temprano. Hazlo antes de pulir la UI, mientras la función aún es fácil de cambiar.
Prueba en casos realistas, límite y sensibles. Usa texto desordenado, jerga, distintos idiomas, hilos largos y peticiones ambiguas. Añade algunos casos de alto riesgo (disputas de facturación, acceso a cuentas, preguntas médicas o legales) incluso si la función no está pensada para ellos, porque los usuarios lo intentarán.
Añade mensajes al usuario, fallbacks y escalado. Decide qué ve el usuario cuando el modelo se niega, está inseguro o rinde mal. Proporciona un valor por defecto seguro (como "preguntar a un humano") y facilita reportar una mala respuesta.
Define monitoreo, incidentes y rollback. Escoge las señales que vigilarás (quejas, tasa de reversión, salidas marcadas), quién recibe alertas y cómo es un "parar la función".
Si algún paso resulta difícil, esa fricción suele señalar dónde está el riesgo.
La forma más rápida de minar la confianza es tratar una buena puntuación en laboratorio como prueba de que eres seguro en el mundo real. Los benchmarks ayudan, pero no muestran cómo la gente empujará, malinterpretará o dependerá de una función en el trabajo diario.
Otro fallo común es ocultar la incertidumbre. Si tu sistema siempre habla con la misma confianza, los usuarios asumirán que siempre tiene razón. Incluso un camino simple de "no estoy seguro" o una nota corta sobre en qué se basó la respuesta puede evitar que la gente tome una salida débil como un hecho.
Los equipos también tienden a probar con sus propios hábitos. Los prompts internos son educados y predecibles. Los usuarios reales están cansados, apurados y creativos. Pegan texto desordenado, piden seguimientos o intentan romper las reglas del modelo.
Cinco errores que se repiten:
Un arreglo práctico es hacer que la responsabilidad sea parte de la construcción. Mantén la lista de verificación dentro de la especificación y exígela antes del lanzamiento: qué datos usaste, en qué falla, quién podría resultar perjudicado y qué harás cuando falle.
Un ejemplo concreto: si despliegas un asistente de IA dentro de un generador de apps, pruébalo con peticiones vagas ("hazlo como Airbnb"), requisitos en conflicto y contenido sensible. Luego establece un plan claro de rollback (snapshots, versionado, interruptor de desactivación rápida) para poder actuar cuando los usuarios reporten daño.
Pega esto en la especificación del producto y complétalo antes de lanzar. Manténlo corto, pero haz que cada respuesta sea específica. Nombra un responsable para cada riesgo.
### 1) Purpose and affected people
- Feature name:
- What decision or action does the AI support (one sentence):
- Who uses it:
- Who is affected even if they never use it (customers, employees, bystanders):
- What a “good” outcome looks like:
### 2) Data used (training, tuning, retrieval, logs)
- Data sources (where it came from and why it’s allowed):
- What you excluded (and why):
- Sensitive data involved (PII, health, finance, kids):
- Data retention period and deletion plan:
- Security and access controls:
### 3) Limits and “do not use” zones
- Known failure modes (give 3-5 concrete examples):
- Languages supported and not supported:
- Inputs it should refuse (or route to a human):
- Cases where it must not be used (legal, medical, hiring, etc.):
### 4) User harm assessment
- Top 5 harms (ranked):
- Mitigation for each harm:
- Who owns each mitigation (name + team):
- What you will tell users (warnings, confidence cues, citations):
### 5) Operations after launch
- Monitoring signals (quality, complaints, bias flags, cost spikes):
- Human review path (when and how escalation happens):
- Rollback trigger (exact threshold or condition):
- Snapshot/version you can revert to:
Ejemplo: si la función redacta respuestas de soporte al cliente, lista daños como "política de reembolso inventada con confianza" y establece la regla de que borradores de baja confianza requieren aprobación antes de enviarse.
Un equipo de soporte añade un asistente de redacción dentro de su herramienta de chat. El asistente redacta respuestas, sugiere siguientes pasos y obtiene contexto del ticket actual. Antes de lanzar, escriben un documento corto que sigue la lista de verificación: qué ve el sistema, qué puede fallar y quién podría resultar perjudicado.
Separan dos fuentes. Primero están los datos de entrenamiento o fine-tuning (tickets pasados, docs internos, políticas de producto). Segundo está el contexto en vivo (mensaje del cliente, plan de cuenta, estado del pedido y notas en la consola del agente).
Escriben las expectativas de privacidad para cada fuente. Los tickets antiguos pueden incluir direcciones o problemas de pago, así que definen reglas: redactar campos sensibles antes de entrenar, evitar almacenar transcripciones completas más tiempo del necesario y registrar solo lo necesario para depurar errores.
Listan puntos débiles en lenguaje claro: el modelo puede inventar políticas, reflejar el tono enojado del cliente, perder el sarcasmo o rendir mal en idiomas menos comunes. También deciden cómo mostrar la incertidumbre, por ejemplo con una etiqueta "Borrador de respuesta, necesita revisión", para que los agentes no lo tomen como hecho.
Añaden una regla: el asistente debe citar el documento interno o el fragmento de política que usó, o debe decir "No pude encontrar una fuente."
Mapean daños probables: clientes engañados por una política de reembolsos inventada, información privada filtrada en la respuesta o lenguaje sesgado que conduce a trato injusto.
Las mitigaciones entran en la especificación como puertas concretas:
Eso convierte "¿debemos desplegarlo?" en comprobaciones escritas que el equipo puede probar antes de que los clientes sufran el daño.
La responsabilidad solo funciona si cambia lo que haces el día del lanzamiento y lo que haces después de que algo salga mal. Tus notas deben acabar en una decisión clara, no en una carpeta de buenas intenciones.
Traduce tu documentación en uno de tres resultados:
Para que esto sea repetible, establece un ritual de revisión ligero: un propietario de producto, un ingeniero y una persona que represente a los usuarios (soporte, investigación u operaciones). Deben firmar las mismas pocas cosas cada vez: notas de fuente de datos, limitaciones conocidas, daños probables y qué ocurre cuando el modelo falla.
Después del lanzamiento, trata la responsabilidad como operaciones. Fija una cadencia (semanal o por release) y normaliza las actualizaciones.
Si prototipas rápido, mantén la misma disciplina. Las herramientas que se mueven rápido aún pueden soportar buenas puertas. Por ejemplo, si construyes en Koder.ai (koder.ai), usa el modo de planificación para definir límites desde el inicio y trata snapshots y rollback como parte de tu plan de seguridad, no solo como una comodidad.
Empieza justo antes de lanzar, cuando usuarios reales vayan a empezar a fiarse de las salidas.
Si esperas hasta después del lanzamiento, estarás documentando incidentes en lugar de prevenirlos, y tendrás menos tiempo (y menos opciones) para añadir salvaguardas o restringir el alcance.
La responsabilidad significa que puedes señalar decisiones escritas sobre:
Si no puedes mostrar esas decisiones y un responsable para ellas, no tienes responsabilidad.
Cualquier función cuyo resultado de un modelo pueda cambiar lo que las personas ven, hacen o cómo son tratadas.
Incluye funciones “pequeñas” como resúmenes o respuestas sugeridas si alguien puede actuar en base a ellas (enviarlas a clientes, negar una solicitud, cambiar una prioridad). Si influye en una decisión, trátala como una superficie de producto real con riesgo real.
Ten un pequeño “conjunto mínimo” por escrito:
Registra lo suficiente para que alguien pueda responder preguntas difíciles rápido:
Escribe las carencias con claridad (por ejemplo: “principalmente usuarios móviles en inglés de EE. UU.; pocos ejemplos de pequeños comercios”).
Empieza con una frase: qué hace el modelo. Luego añade los límites de “no usar”.
Incluye una lista corta de:
Separa error de daño:
Después escribe algunos escenarios cortos: quién es el usuario, qué pregunta, qué podría devolver el modelo y qué acción seguiría. Puntúa cada escenario por y , y asigna un responsable a cada mitigación.
Usa un flujo con puertas desde prototipo hasta lanzamiento:
Si una puerta se siente difícil, ahí suele estar el riesgo real.
Errores comunes:
Una solución práctica: mantener la lista de verificación dentro de la especificación del producto y exigir la aprobación antes del lanzamiento.
La velocidad no elimina la responsabilidad. Si construyes con una herramienta de chat como Koder.ai, mantiene la misma disciplina:
La iteración rápida está bien siempre que puedas explicar lo que lanzaste y cómo responderás cuando falle.
Manténlo breve, pero haz que cada afirmación sea comprobable.
Añade 3–5 ejemplos concretos de salidas malas para que quienes no son ingenieros entiendan los bordes.