El NIST AI Risk Management Framework tiene una virtud que casi ninguna otra referencia del sector comparte: nadie te certifica en él. No hay auditor, no hay sello, no hay ciclo de vigilancia. Eso lo vuelve especialmente útil para una organización mediana, porque puedes adoptar la parte que te sirve sin comprometerte a sostener un aparato completo. También lo vuelve fácil de abandonar a mitad de camino, porque nadie va a venir a preguntar.
El marco se organiza en cuatro funciones —gobernar, mapear, medir y gestionar— que suenan abstractas hasta que las conviertes en tareas con dueño y fecha. Eso es lo que intentamos aquí: qué hace concretamente un equipo de riesgo, compliance o TI que no tiene oficina de riesgo dedicada, ni presupuesto de certificación, ni un científico de datos disponible.
Gobernar: la función que no se puede saltar
Gobernar es la función transversal, y en organizaciones medianas es donde más se pierde el tiempo, porque se confunde con estructura. No necesitas un comité de doce personas ni una política de veinte páginas. Necesitas tres cosas que quepan en una carpeta compartida.
La primera es una persona con nombre que responda por el uso de IA en la organización y tenga autoridad para detener algo. Si esa autoridad no existe, el resto del marco produce documentos sin consecuencia. La segunda es una regla escrita y corta sobre qué se puede hacer, qué no, y a quién preguntar cuando el caso no está cubierto. La tercera es un registro de decisiones: qué se aprobó, con qué condiciones, quién lo aprobó y cuándo. Ese registro es, en la práctica, la mitad de la evidencia que vas a necesitar si algún día alguien pregunta.
Mapear y medir: las dos que se confunden
Mapear es entender el contexto antes de evaluar nada. Medir es comprobar cómo se comporta el sistema. Se confunden porque ambas producen documentos parecidos, y el resultado típico es que el equipo escribe una descripción técnica detallada y cree que ya evaluó el riesgo.
Mapear, en una página por caso de uso
Para cada sistema de IA que uses, la ficha necesita responder qué decisión concreta cambia respecto de cómo se hacía antes, sobre quién se aplica, qué datos consume, qué ocurre si se equivoca y qué es lo peor que puede pasar si alguien lo manipula. La pregunta que casi siempre falta es quién se ve afectado sin ser usuario: el postulante que no consigue la entrevista, el cliente al que se le asignó otro precio, el proveedor que quedó fuera de una preselección. Esa persona no va a reclamar por el canal de soporte de la herramienta, y por eso el sistema puede fallar mucho tiempo sin que nadie se entere.
Medir, sin instrumental sofisticado
Aquí es donde las organizaciones medianas se paralizan, porque asumen que medir exige métricas estadísticas de equidad y una plataforma de observabilidad. No es así, al menos no para empezar. Un conjunto de treinta o cuarenta casos de prueba representativos, con la respuesta esperada acordada de antemano, ya permite comparar versiones y detectar regresiones. Definir un criterio de aceptación antes del despliegue —qué tasa de error es tolerable y para qué tipo de error— vale más que cualquier tablero posterior.
Y conviene recordar que medir también incluye lo cualitativo: los reclamos recibidos, las veces que un revisor humano corrigió la salida, los casos que el equipo tuvo que rehacer. Si tu sistema tiene revisión humana y nadie lleva la cuenta de cuántas veces el humano cambió la decisión, estás desperdiciando la métrica más barata y más honesta que tienes.
Gestionar: decidir con nombre y fecha
Gestionar es la función que convierte el análisis en acción, y se reduce a cuatro decisiones que hay que dejar por escrito. Qué riesgos se tratan primero, con qué control concreto. Qué riesgo residual se acepta y quién firma esa aceptación —una aceptación sin firmante es un riesgo simplemente ignorado—. Qué se hace cuando algo sale mal, con un camino de escalamiento que exista antes del incidente y no se improvise durante. Y bajo qué condiciones se apaga o se retira un sistema, criterio que casi nadie escribe y que resulta decisivo cuando el proveedor cambia el modelo por debajo.
Un riesgo aceptado sin firmante no es un riesgo aceptado: es un riesgo ignorado con mejor redacción.
Un plan de tres meses sin presupuesto
El orden que nos ha funcionado con equipos pequeños es este. El primer mes se dedica a gobernar y mapear: designar al responsable, escribir la regla corta y levantar las fichas de los casos de uso que ya existen, que siempre son más de los que el equipo de TI creía. El segundo mes se usa para medir los dos o tres casos de mayor exposición, construyendo el conjunto de pruebas y fijando criterios de aceptación. El tercero se destina a gestionar: priorizar, implementar los controles baratos y de alto efecto, y dejar establecido el camino de incidentes y de retiro. Los controles concretos que rinden más por unidad de esfuerzo los listamos en seis controles para el próximo trimestre.
Dos aclaraciones honestas para terminar. La primera es que el marco es estadounidense y de adopción voluntaria: no te hace cumplir ninguna obligación legal chilena por sí mismo, y su relación con lo que se está discutiendo localmente todavía está en movimiento —lo seguimos en nuestra página sobre la Ley IA en Chile—. La segunda es que su valor real para una organización mediana no está en el contenido, que es en buena parte sentido común ordenado, sino en la estructura: te da un vocabulario común y un orden defendible para explicar por qué hiciste lo que hiciste. Cuando un cliente grande, una aseguradora o un regulador pregunte, la diferencia entre una respuesta sólida y una improvisada no va a ser cuánto invertiste, sino si puedes mostrar las cuatro funciones cubiertas con evidencia mínima y fechada.