Un sistema de IA que responde correos, evalúa una solicitud o redacta un asesoramiento, lo hace basándose en lo que le está permitido. No en lo que puede hacer —a menudo es más de lo deseado— sino en lo que le está permitido. Las reglas de agente son los límites establecidos de ese mandato: qué decisiones toma un sistema de forma autónoma, cuáles somete a consideración, y cuáles quedan fuera de su alcance, sea cual sea la entrada.
Sin esas reglas, un sistema toma decisiones implícitas. Alguien ha establecido en algún lugar un umbral, elegido un ejemplo, ignorado una excepción. Eso funciona en un piloto con un puñado de casos de prueba. Se convierte en riesgo invisible en cuanto el sistema opera a escala y ya nadie puede reconstruir por qué hizo lo que hizo.
Las reglas de agente a menudo se tratan como algo propio de la fase de implementación —un ajuste que gestiona el proveedor. Se trata de un error con consecuencias. La regla de que un siniestro por debajo de determinado importe se gestiona automáticamente es una decisión de gobierno sobre aceptación de riesgo, no un parámetro técnico. Quien deja esa decisión en manos de la técnica, solo descubre las consecuencias cuando algo sale mal.
Esta es una de las razones por las que la diferencia entre soportar la IA y que la IA se haga cargo se subestima tan a menudo. Hacerse cargo —dejar que una tarea se ejecute— es visible y concreto. Soportar —que la organización determine dentro de qué límites ocurre eso, quién lo verifica y qué cambia cuando la situación cambia— permanece sin discutirse hasta la primera vez que algo sale mal.
Las reglas de agente establecen qué puede decidir un sistema. No resuelven si la organización es capaz de vigilar esas reglas. Un conjunto de reglas que nadie revisa periódicamente, que queda obsoleto frente a la legislación modificada o que nunca se ajusta tras un incidente, es completo sobre el papel e inútil en la práctica.
Ese es precisamente el límite de lo que estas reglas pueden hacer. Son un instrumento, no una garantía. Una organización sin una responsabilidad clara sobre la calidad de los datos, o sin infraestructura que haga rastreable qué decisión se tomó, cuándo y por qué, tiene poco asidero solo con reglas —por muy precisas que estén redactadas. La regla es tan fiable como los fundamentos sobre los que se sostiene.
En la mayoría de las direcciones no hay consenso sobre cuánto mandato debería tener un sistema. Un directivo quiere velocidad y acepta que un sistema decida de forma autónoma dentro de márgenes amplios. Otro quiere ver cada resultado controlado antes de que salga al exterior. Ambas posiciones son defendibles, y esa diferencia explica en gran medida por qué su dirección no se pone de acuerdo sobre el ritmo de la IA.
Las reglas de agente concretan esa conversación. En lugar de discutir sobre la ambición en términos generales, la pregunta se convierte en: ¿a partir de qué importe, qué excepción, qué tipo de cliente el sistema pasa a un humano? Es una pregunta que se puede responder, siempre que la organización sepa qué puede soportar realmente —no solo qué quiere.
Un error frecuente es tratar las reglas como un trabajo puntual. Establecidas, implementadas, listo. En la práctica, las circunstancias sobre las que se basa una regla cambian: nueva legislación, una cartera de clientes distinta, un incidente que revela un punto ciego. Las reglas que no se adaptan a eso llegan, en algún momento, a proteger contra un riesgo que ya no existe, y no contra el riesgo que sí existe.
Esa es también la razón por la que con qué frecuencia debe repetirse una medición de madurez es una pregunta que va más allá de una cita en el calendario. Las reglas que hoy son adecuadas para el nivel de la organización pueden dejar de serlo en un año —en ambos sentidos. Una organización que ha ganado madurez puede justificar más mandato. Una organización que ha crecido sin que la vigilancia crezca con ella puede resultar capaz de soportar menos de lo que las reglas permiten sobre el papel.
Este texto no describe pasos de implementación ni una plantilla para un documento de reglas. Cada organización establece sus propios límites, basados en su propia disposición al riesgo y su propia supervisión. Lo que sí es válido para toda organización: quien redacta las reglas de agente solo después de que un sistema ya esté funcionando, las redacta bajo presión de tiempo y a menudo a raíz de un incidente. Es la forma más cara de aprenderlo. La pregunta no es si se necesitan reglas, sino si existen antes de que la práctica las ponga a prueba. Y quien solo mira lo que ocurre en la ventana de chat, se pierde lo que no ve si solo conoce la ventana de chat —es decir, todo lo que se ha establecido de antemano y lo que ocurre en cuanto un caso queda fuera del límite fijado.
Las reglas de agente determinan los límites del mandato. No dicen nada sobre qué parte del trabajo realmente es apta para ser asumida, ni qué debe seguir en manos de una persona por otras razones. Esa pregunta la responde el escáner de trabajo de FTE TO AI: calcula, por tarea, qué parte del trabajo puede asumirse, y sienta así la base sobre la que después pueden construirse las reglas de agente —las reglas sin una imagen clara del trabajo en sí son difíciles de fundamentar, y un análisis de tareas sin reglas claras no produce un límite útil.
Vraag maar wat er moet staan voordat AI in uw organisatie kan landen.
Answers come from this site’s knowledge base. Not tailored advice, and not a scan of your company.