Ponerle un número al riesgo de una automatización puede ser útil. También puede producir una falsa sensación de seguridad si nadie recuerda de dónde salió ese número.
Por eso una calculadora de riesgo debería usarse como herramienta de triage: sirve para decidir qué casos merecen más revisión, no para declarar que un sistema es «seguro» porque obtuvo 8 y no 12.
Ese matiz importa especialmente con IA. El riesgo no depende solo del modelo. Depende de qué datos toca, qué puede hacer por su cuenta, cuántas personas afecta y qué tan fácil es corregir una decisión equivocada.
Antes del puntaje, define la decisión
«Usar IA en finanzas» es demasiado amplio para evaluar nada. «Permitir que un modelo sugiera la categoría contable de una factura, con aprobación humana antes de registrar el asiento» sí es una decisión concreta.
También es muy distinto a «permitir que un agente apruebe y pague automáticamente facturas por debajo de cierto monto». Las dos usan IA; la segunda tiene capacidad de acción y exposición financiera directa.
Una evaluación útil empieza por describir el flujo en una frase: entrada → decisión o acción → persona o sistema afectado → posibilidad de corrección.
Cuatro preguntas que cambian el nivel de revisión
| Factor | Pregunta práctica |
|---|---|
| Sensibilidad | ¿Qué datos ve el sistema y qué daño produciría una exposición o uso indebido? |
| Reversibilidad | Si se equivoca, ¿puedo deshacer la acción sin consecuencias duraderas? |
| Escala | ¿Un error afecta a una persona o puede propagarse a cientos o miles? |
| Derechos / regulación | ¿La decisión toca empleo, crédito, salud, acceso a servicios u otra materia regulada? |
No son los únicos factores posibles. Son una base suficientemente simple para no convertir el análisis en un proyecto de consultoría antes de haber probado el caso de uso.
Un ejemplo: la misma IA, dos riesgos muy distintos
Caso A: un modelo sugiere una respuesta para una pregunta frecuente de un cliente. Un empleado la revisa antes de enviarla. La información no es especialmente sensible y un error se corrige con otro mensaje.
Caso B: un sistema clasifica candidatos y descarta automáticamente a quienes no superan un umbral. Aquí la decisión puede afectar oportunidades laborales, operar a gran escala y ser difícil de detectar para quien fue excluido.
No hace falta una fórmula sofisticada para entender que el segundo caso merece controles mucho más fuertes.
En la Unión Europea, por ejemplo, el Reglamento de IA incluye determinados usos en empleo y selección dentro de la categoría de sistemas de alto riesgo, con matices y excepciones definidos en el propio reglamento. Esa es una buena ilustración de por qué un «score» interno nunca sustituye la revisión jurídica aplicable al caso real.
No mezcles riesgo con cumplimiento
Un flujo puede tener riesgo operativo bajo y aun así incumplir una obligación concreta. También puede cumplir formalmente una lista de requisitos y seguir siendo una mala idea.
Por eso conviene separar dos capas:
- Evaluación de riesgo: qué puede salir mal, a quién afecta y cuán grave sería.
- Revisión de cumplimiento: qué leyes, contratos, políticas internas o compromisos regulatorios aplican.
El AI Risk Management Framework de NIST parte de una lógica parecida: gestionar riesgo de IA a lo largo de su ciclo de vida y adaptarlo al contexto de cada organización. NIST no propone una cifra universal que certifique una automatización.
Una escala simple, sin fingir precisión
Si necesitas comparar varios casos, puedes puntuar cada factor de 1 a 5. Pero el resultado debería leerse como una prioridad de revisión, no como probabilidad matemática de fallo.
Por ejemplo, un caso con datos sensibles, baja reversibilidad y alto alcance debería subir automáticamente de nivel. Si además toca derechos o un proceso regulado, puede merecer revisión legal aunque el resto del puntaje sea modesto.
La regla útil es que algunos factores funcionen como banderas, no como números que se pueden compensar. Un riesgo serio de discriminación no desaparece porque la integración sea barata y el proveedor tenga buen soporte.
Qué debería entregar una buena evaluación
Más que un semáforo, yo esperaría cinco cosas:
- la descripción concreta del flujo evaluado;
- los factores que hicieron subir o bajar el riesgo;
- los supuestos que todavía no están comprobados;
- un responsable de revisar el caso;
- una fecha o condición para volver a evaluarlo.
Eso permite entender por qué se tomó una decisión y revisarla cuando cambian el modelo, los datos, la integración o el número de usuarios.
Cuándo una hoja de cálculo es suficiente
Para un equipo pequeño con pocos casos de uso, una hoja compartida puede ser mejor que comprar una plataforma. Lo importante es que el hábito exista: registrar el caso, puntuarlo con criterios consistentes, documentar banderas y asignar dueño.
Una plataforma empieza a aportar más cuando hay muchas evaluaciones, varias áreas, necesidad de historial, aprobaciones, evidencia y controles de acceso. Comprar ese software antes de tener el proceso suele producir un repositorio elegante que nadie mantiene.
Nuestra Calculadora de Riesgo de IA está pensada precisamente como primer filtro. Úsala para estructurar la conversación y detectar dónde hace falta mirar más; no como sello de cumplimiento.
El objetivo no es convertir el juicio en una cifra. Es evitar que una automatización llegue a producción sin que nadie haya escrito qué puede salir mal y quién responde si ocurre.
