Artículo
OCDE: qué revelan 25 entrevistas sobre agentes de IA
La noticia y su método
La OCDE publicó el 16 de septiembre de 2026 un estudio cualitativo sobre agentes de IA. Entrevistó a 25 de 74 organizaciones contactadas, en once países, sobre desarrollo, despliegue y gobernanza. Recoge perspectivas de participantes, no impactos económicos medidos.
Las entrevistas describen madurez desigual y gobernanza todavía incipiente.
Participaron quienes aceptaron dentro del plazo, entre actores ya involucrados con agentes. No ofrece representatividad mundial, métricas cuantitativas ni evaluaciones independientes de resultados.
Fuente: Agentic AI in organisations: Early insights from practitioner interviews, OCDE.
Análisis propio: convertir la pregunta en una decisión
Para leer este trabajo, proponemos separar tres preguntas: qué tarea se quiere delegar, qué decisiones podrá tomar el agente y cómo sabremos que respetó esa delegación. Son preguntas editoriales para orientar una evaluación. No constituyen un protocolo de la OCDE.
Una entrevista puede ayudarnos a formular preguntas sobre una implementación. La autorización de una compra concreta exige otra clase de evidencia: el dato consultado, la regla aplicable y la decisión registrada. Ese cambio de escala importa. El responsable de una operación necesita poder revisar por qué se avanzó o por qué se detuvo una acción, incluso cuando la propuesta inicial parece razonable.
Caso hipotético: proponer la reposición de inventario
Imaginemos una distribuidora de repuestos que quiere preparar propuestas de reposición. Su agente consulta existencias, pedidos pendientes y una lista aprobada de proveedores. Después reúne una propuesta para la persona encargada de compras. Este ejemplo es ficticio: no describe una organización entrevistada ni resultados de una implementación real.
El encargo inicial sería acotado: detectar un posible faltante y preparar un borrador revisable. La empresa tendría que decidir qué catálogo puede consultar, quién mantiene las reglas y dónde queda el borrador. También debería precisar qué significa completar la tarea. Encontrar un proveedor alternativo no equivale a contar con permiso para contratarlo; enviar una propuesta tampoco equivale a obtener una aprobación.
El primer entregable útil sería una ficha de decisión con referencias verificables, no una orden enviada automáticamente.
Una tabla para hacer visible la delegación
La siguiente tabla es una propuesta editorial para ese caso. Antes de implementar, la empresa tendría que reemplazar cada límite por una regla propia aprobada. Aquí no fijamos importes, porcentajes ni umbrales de stock.
| Función | Permiso | Límite | Evidencia requerida |
|---|---|---|---|
| Consultar existencias | Leer el inventario autorizado | Sin corregir movimientos | Registro consultado y fecha del dato |
| Preparar reposición | Crear un borrador interno | Sin enviarlo al proveedor | Productos, cantidades propuestas y regla aplicada |
| Proponer una excepción | Solicitar revisión de compras | Sin aprobar su propia solicitud | Motivo y condición que queda fuera de la regla |
| Emitir la orden | Reservado al responsable autorizado | Requiere aprobación vinculada al borrador vigente | Aprobación, versión y destinatario |
Qué hacer cuando los datos no alcanzan
Supongamos que el inventario muestra unidades disponibles, pero el registro de reservas no está actualizado. El agente no debería resolver esa contradicción mediante una suposición silenciosa. En nuestro diseño propuesto, dejaría la reposición pendiente e indicaría qué dato falta para continuar.
La persona revisora necesitaría distinguir una existencia física de una unidad comprometida. Por eso pediríamos que la propuesta conserve las referencias de ambos registros y el momento de consulta. Si después cambia una reserva, la aprobación anterior tendría que revisarse respecto del nuevo borrador.
Esto permite concretar una pregunta de evaluación: ¿el sistema reconoce información insuficiente y explica la detención? La respuesta debería observarse en el caso preparado, sin deducirla de una explicación convincente del agente sobre sus propias capacidades.
La excepción que debe llegar a una persona
Ahora imaginemos que el proveedor habitual no tiene disponibilidad y aparece una alternativa fuera de la lista aprobada. El agente puede describir la opción y señalar la excepción. En este diseño, no puede incorporar al proveedor por su cuenta ni transformar una recomendación en una orden.
Escalar requeriría entregar una solicitud comprensible: qué producto falta, qué regla impide continuar, qué alternativa se propone y quién puede decidir. El revisor también debería poder rechazarla o pedir información adicional. Un botón de aprobación sin acceso a esos antecedentes dejaría incompleta la revisión que estamos proponiendo.
Si se autoriza una excepción, esa decisión debe corresponder al producto, proveedor y borrador concretos. Cambiar el destinatario después de la aprobación exigiría una nueva revisión.
La evidencia debe seguir a la decisión
Para este caso, proponemos conservar una cadena breve: solicitud original, datos utilizados, borrador, excepción si existe y resolución de la persona autorizada. Cada elemento debería permitir localizar el anterior. El objetivo es reconstruir una decisión sin depender de recordar una conversación.
Conviene definir también qué información verá cada participante. La persona que valida cantidades puede necesitar acceso al inventario; quien aprueba un proveedor necesitará sus antecedentes comerciales. Diseñar esa separación exige revisar los permisos de la empresa, sin copiar automáticamente todo el contexto en cada solicitud.
El registro debería mostrar los intentos detenidos. Si el agente propuso enviar una orden sin permiso y una barrera lo impidió, ese intento sería un hallazgo para revisar, aunque no se hubiera producido una compra.
Cómo preparar una evaluación que pueda fallar
Antes de conectar este diseño a compras reales, prepararíamos situaciones con respuesta esperada: datos consistentes, inventario contradictorio, proveedor no autorizado y un borrador modificado después de aprobarse. Cada situación permite comprobar una frontera distinta del permiso.
Registraríamos lo que hizo el sistema, la evidencia que presentó y el motivo de cualquier intervención humana. Si una tarea termina, revisaríamos además si lo hizo por el camino permitido. Si queda pendiente, comprobaríamos si la detención corresponde a una condición prevista o a un problema que nadie había considerado.
Para decidir una ampliación, el equipo tendría que acordar previamente qué resultados acepta y cuáles obligan a corregir el diseño. Aquí no asignamos tasas de éxito: faltan ejecuciones observadas y criterios propios de la operación.
La decisión siguiente: una tarea con fronteras revisables
El siguiente paso para la distribuidora hipotética sería elegir una sola tarea y escribir sus permisos antes de habilitar acciones. La propuesta puede empezar como un borrador interno, con revisión humana y evidencia localizable. Cualquier ampliación requeriría una decisión explícita sobre la nueva responsabilidad.
Para seguir aprendiendo y conversar sobre tus casos, entra a la Comunidad gratuita.
Si trabajas en una institución pública, continúa con BID: qué revela una encuesta sobre IA pública. Para pensar qué permite concluir una evaluación, lee SpireClimb: cómo diseñar una prueba útil para tu agente.