En enero de 2023, el Instituto Nacional de Estándares y Tecnología de Estados Unidos, el NIST, publicó un marco voluntario de gestión de riesgo para sistemas de IA — hoy adoptado por empresas de varios países, incluso fuera de Estados Unidos, como referencia para decidir qué automatizar y cómo. Una de las cuatro funciones centrales de ese marco se llama "Mapear", y su lógica es directa: antes de decidir si un sistema de IA debe seguir adelante, la empresa necesita entender el contexto — para qué sirve, a quién puede afectar, y cuál es el costo, incluso no financiero, de un error.
El documento es explícito sobre el momento en que esto debe ocurrir: después de mapear el contexto, la organización toma una decisión inicial de continuar o no con ese sistema. No después de construirlo. Antes.
En la práctica de la mayoría de las empresas, ese paso simplemente no existe como proceso formal. Alguien identifica una tarea repetitiva, arma una automatización con IA para resolverla, y solo descubre — si llega a descubrirlo — que esa tarea decidía algo serio sobre una persona, después de que el error ya ocurrió.
Esto no es falta de cuidado de quien construyó la automatización. Es la ausencia de un paso anterior: nadie preguntó, antes de empezar, cuánto pesaba realmente esa decisión específica. Hacer la pregunta correcta en el momento correcto sale más barato que cualquier corrección hecha después de que el sistema ya está en producción y alguien ya fue afectado por él.
No toda automatización tiene el mismo riesgo
La Unión Europea llegó a una conclusión parecida por otro camino: la regulación. El bloque organiza los sistemas de IA en cuatro niveles de riesgo. En la cima, el riesgo inaceptable — hoy prohibido. Justo debajo, el alto riesgo: sistemas usados en decisiones sobre empleo, acceso al crédito, educación, infraestructura crítica o identificación biométrica, que pueden afectar la seguridad o los derechos fundamentales de una persona. Después viene el riesgo de transparencia, para sistemas que solo necesitan avisar que una persona está interactuando con IA. Y en la base, la mayoría de los casos de uso actuales: riesgo mínimo, como un filtro de spam.
El punto que le importa a cualquier empresa, esté o no bajo esa regulación, es la lógica detrás de la pirámide: la misma etiqueta de "automatización con IA" cubre situaciones completamente distintas. Un asistente que resume las notas de una reunión interna y un sistema que ayuda a decidir quién recibe un préstamo no deberían pasar por el mismo proceso de aprobación, ni por el mismo nivel de supervisión. Tratarlos como si fueran lo mismo es donde empieza la mayoría de los problemas.
Automatizar todo de la misma forma es el error
La respuesta más común al entusiasmo por la IA dentro de una empresa es "automaticemos todo" — una frase que, sin un filtro de riesgo detrás, produce dos efectos malos al mismo tiempo, uno en cada extremo.
En el extremo de bajo riesgo, aplicar el mismo proceso pesado de revisión y aprobación a una tarea trivial — como resumir un documento interno — frena la adopción. Las personas dejan de usar la herramienta porque el proceso alrededor de ella es más lento que hacer la tarea a mano. En el extremo de alto riesgo, el problema es el opuesto y mucho más grave: una automatización que decide algo sobre el empleo, el crédito o la salud de alguien sigue con el mismo nivel de supervisión informal que un resumen de reunión — es decir, casi ninguna.
El propio marco del NIST nombra este segundo riesgo de forma directa: antes de decidir avanzar con un sistema, la organización necesita examinar los costos potenciales, incluidos los no monetarios, de errores esperados o reales de ese sistema. Un error en un resumen de reunión cuesta un malentendido. Un error en una decisión sobre una persona cuesta mucho más — y ese costo suele aparecer después, cuando ya es tarde para prevenirlo con un mejor proceso.
La salida no es elegir entre los dos extremos — ni todo bloqueado, ni todo suelto. Es reconocer, caso por caso, en qué extremo cae cada automatización antes de decidir cómo debe operar. Una pregunta simple suele bastar para separar las dos situaciones: si esta automatización se equivoca hoy, ¿alguien fuera del equipo de tecnología va a sentir el efecto? Si la respuesta es sí, el nivel de supervisión tiene que estar a la altura.
Lo que tiene que existir en la práctica
Clasificar el riesgo antes de automatizar solo funciona si algunos mecanismos concretos vienen junto con eso — no como promesa, sino como parte del diseño.
Aprobación según el riesgo. Cuanto más alto sea el riesgo identificado, más debería detenerse la automatización y pedir confirmación de una persona antes de continuar — no en toda automatización, solo en las que deciden algo serio.
Registro de auditoría. Toda automatización relevante debería registrar qué se decidió, con qué información y bajo qué autorización, de forma consultable después — no solo mientras funciona bien, sino especialmente cuando algo sale mal.
Conocimiento aprobado con fuentes. La información que alimenta una automatización de alto riesgo necesita un dueño, una versión vigente y revisión periódica — no puede venir de un documento desactualizado que ya nadie lee.
Acceso según el rol. Solo quien tiene autoridad real sobre esa rutina debería poder crear, ajustar o aprobar una automatización clasificada como de alto riesgo — no cualquier persona con acceso a la herramienta.
Revisión periódica de la clasificación. El riesgo de una automatización cambia con el tiempo — cuando empieza a alimentar otro sistema, a atender a otro público, o a operar a mayor escala. La clasificación inicial necesita revisarse, no hacerse una vez y olvidarse.
Por eso Skyller ya viene con más de 170 modelos de políticas y procesos listos, que anticipan qué nivel de aprobación y registro suele exigir cada tipo de rutina — en vez de dejar que cada equipo lo descubra solo, la primera vez que algo sale mal.
La ganancia de clasificar antes de decidir
La ganancia más inmediata es de velocidad — aunque en la dirección que menos se espera. Una empresa que clasifica el riesgo antes de automatizar puede liberar rápido las tareas triviales, precisamente porque no acumula proceso donde no hace falta. El proceso pesado queda reservado para donde el riesgo realmente lo exige.
La segunda ganancia aparece más tarde, y es la que evita el dolor de cabeza mayor: cuando algo sale mal en una automatización de alto riesgo — y en algún momento algo saldrá mal — la diferencia entre una empresa que clasificó el riesgo antes y una que no lo hizo es la diferencia entre explicar en minutos lo que pasó, con registro y criterio documentados, y pasar semanas reconstruyendo, sin ninguna certeza, qué decidió exactamente la automatización y por qué.
También hay un efecto sobre la confianza interna. Un equipo que sabe que la automatización de alto riesgo fue revisada y aprobada la usa con mucha más seguridad que un equipo que sospecha, con razón, que nadie evaluó realmente qué hace ese sistema.
Ninguna de estas ganancias depende de acertar la clasificación a la perfección desde el primer intento. Depende de que exista una clasificación, revisable, que le dé a la empresa un motivo concreto para tratar dos automatizaciones de forma distinta — en vez de decidirlo por impulso, cada vez de una manera diferente.
Cinco preguntas antes de automatizar
Antes de aprobar la próxima automatización con IA, estas cinco preguntas resuelven la mayoría de los casos:
- ¿Quién es afectado si esto sale mal? Un cliente, un colaborador, un proveedor, o solo el propio equipo interno — la respuesta ya indica el nivel de riesgo.
- ¿Cuánto cuesta corregir el error, y quién paga ese costo? Un malentendido interno no es lo mismo que una decisión que hay que revertir después de que ya afectó a alguien fuera de la empresa.
- ¿De dónde viene la información usada para decidir? Un documento con dueño y versión vigente es distinto de un archivo perdido que nadie revisa hace meses.
- ¿Quién revisa antes de que la decisión sea válida? Si la respuesta es "nadie", esa es la brecha que hay que cerrar antes que cualquier otra cosa.
- ¿Qué queda registrado después? Sin registro, una auditoría o un reclamo se convierte en reconstruir memoria en vez de consultar un historial.
