La evaluación de impacto algorítmico tiene un problema de reputación merecido. En muchas organizaciones se convirtió en un formulario que el equipo de proyecto completa al final, cuando el sistema ya está construido y la decisión ya está tomada, con el único propósito de cerrar un requisito. Ese documento no protege a nadie: ni a las personas afectadas, ni al proyecto, ni a quien lo firma.
Hecha en el momento correcto, en cambio, es la única herramienta que obliga a una organización a mirar su sistema desde el lado de quien lo recibe. No es un trámite legal ni un ejercicio de documentación: es una conversación estructurada que termina con alguien asumiendo un riesgo residual por escrito. Todo lo demás es soporte de esa firma.
Cuándo corresponde hacerla
Si tu criterio es "para todo sistema de IA", el proceso se va a diluir y ninguna evaluación va a ser seria. La disciplina de decir que no también es parte del método. Los disparadores que en nuestra experiencia justifican una evaluación completa son bastante identificables.
- El sistema condiciona el acceso de una persona a algo. Crédito, empleo, un beneficio, un tratamiento, un cupo, un precio, un nivel de servicio. Cuando la salida del modelo se traduce en que alguien recibe o no recibe, corresponde evaluar.
- Sustituye o condiciona fuertemente una decisión que antes tomaba una persona. No importa si formalmente hay un revisor humano; importa si ese revisor en la práctica puede y suele apartarse de la recomendación.
- Se aplica a personas que no eligieron interactuar con él. Un postulante, un usuario de un servicio esencial, alguien que no tiene alternativa. La ausencia de salida cambia por completo el cálculo de riesgo.
- Trata datos personales sensibles, o los infiere. Deducir atributos sensibles a partir de datos que no lo son es el caso más frecuente y el que menos se detecta.
- Opera en un dominio regulado o sobre población vulnerable. Salud, educación, servicios financieros, menores de edad, personas en situación de dependencia.
Un asistente que resume documentación pública para uso interno no necesita una evaluación de impacto; necesita reglas de uso claras. Confundir ambas cosas es lo que hace que el proceso pierda credibilidad.
Qué preguntas incluye
Propósito y alternativa
Qué decisión concreta cambia respecto de cómo se hacía antes, y por qué se eligió este camino. Aquí importa fijar la línea de comparación correcta: la alternativa no es un proceso perfecto, es el proceso humano actual, con sus propios errores y sesgos. Pero eso tampoco absuelve, porque un sistema automatizado escala el error de un modo que un evaluador humano no puede. Documentar qué alternativas se consideraron y por qué se descartaron es la sección que los equipos más omiten y la que un auditor más agradece.
Personas afectadas
Quiénes son, incluidas las que no son usuarias del sistema. A quién le duele más un error y qué tipo de error le duele: no es lo mismo un falso positivo que un falso negativo, y esa asimetría debería estar escrita antes de definir umbrales. Pregunta además quién se ve afectado sin forma de enterarse, porque ese grupo no genera reclamos y por lo tanto no aparece en ninguna métrica.
Datos y comportamiento
De dónde vienen los datos, con qué base de tratamiento, a quién representan bien y a quién no. Qué grupos están subrepresentados y qué se hizo al respecto. Cómo se comporta el sistema en los segmentos relevantes, no solo en promedio: el promedio esconde exactamente los casos que motivan la evaluación. Es el punto donde el análisis de sesgo deja de ser un principio y se vuelve un control medible, cosa que desarrollamos en este artículo.
Controles y salida
Qué revisión humana existe y si tiene autoridad y tiempo real para revertir una recomendación —un revisor con dos minutos por caso y una meta de productividad no es un control—. Qué se le explica a la persona afectada. Por dónde puede impugnar. Qué se monitorea después del despliegue, con qué frecuencia y bajo qué umbral se detiene el sistema. Ese criterio de apagado es el que casi nunca está escrito y el que define si la organización realmente puede reaccionar.
Quién la firma
Tres roles y una exclusión. El dueño del caso de uso la propone y responde por su contenido. Una función independiente —riesgo, compliance, privacidad— la revisa, y su independencia debe ser estructural: no puede reportar a quien entrega el proyecto. Y alguien con autoridad suficiente acepta el riesgo residual con nombre y fecha, decisión que en casos de alto impacto corresponde al órgano de gobierno de IA y no a una jefatura de proyecto.
La exclusión: el proveedor del sistema no firma la evaluación de impacto de su propio producto. Su documentación técnica es insumo valioso y muchas veces indispensable, pero la evaluación es sobre el uso que tú le das en tu contexto, y esa responsabilidad no se externaliza junto con el software.
El entregable de una evaluación de impacto no es el documento: es la firma de alguien que acepta el riesgo residual con nombre y fecha.
Cómo documentarla para que sirva después
El estándar práctico es simple: alguien que no estuvo en las reuniones debería poder reconstruir el razonamiento tres años después. Eso exige versionar el documento y amarrarlo a una versión concreta del sistema, porque una evaluación sin versión asociada no prueba nada sobre lo que está en producción hoy. Exige también apoyar cada afirmación en evidencia enlazada —resultados de pruebas, documentación de datos, actas— y no en aseveraciones del propio equipo.
Dos prácticas separan una evaluación creíble de una ceremonial. La primera es registrar los desacuerdos: si el documento muestra que todos estuvieron de acuerdo en todo, se lee como teatro. Deja constancia de las objeciones, de las preguntas abiertas y de por qué se avanzó igual. La segunda es fijar los gatillos de reevaluación —cambio de versión del modelo, cambio en la población atendida, incidente, ampliación de escala— para que la evaluación tenga fecha de vencimiento explícita.
Conviene además ser honesto sobre el marco de referencia: existe orientación internacional sobre evaluación de impacto de sistemas de IA en la familia de normas ISO/IEC, y la discusión regulatoria local sigue abierta, de modo que las exigencias formales todavía se están definiendo —lo seguimos en nuestra página sobre la Ley IA en Chile—. Esa incertidumbre no justifica esperar. Una evaluación bien hecha resiste cualquiera de los regímenes en discusión, porque todos preguntan lo mismo en el fondo: qué podía salir mal, quién lo revisó, qué se decidió y quién se hizo cargo. Si tienes un sistema en producción que toca decisiones sobre personas y no puedes responder esas cuatro preguntas con un documento fechado, ese es el trabajo de esta semana.