Desarrollar frente a comprar: agentes de IA para operaciones de riesgo reguladas

Última actualización: septiembre de 2026

El debate entre desarrollar o comprar agentes de riesgo de IA casi siempre se plantea como una cuestión de costes, y esa es la pregunta equivocada para empezar. Un prototipo que lee una alerta, extrae el historial del cliente y redacta una recomendación de resolución puede estar listo en una semana, y una vez que su equipo lo ve funcionar, comprar parece pagar por algo que ya ha demostrado que puede hacer. Lo que el prototipo no le muestra es la parte que nunca termina: la evaluación continua, la deriva que hay que detectar, las modificaciones de los analistas que hay que registrar, la documentación que debe sobrevivir a la persona que la escribió y un marco de supervisión que cambió en abril y volverá a cambiar. Estas obligaciones existen en ambas opciones. La decisión es quién asumirá cada una de ellas dentro de tres años.

Resumen rápido (TL;DR)

• El prototipo no es lo que se está decidiendo. Desarrollar un agente es barato en comparación con gestionarlo en una cola de alertas regulada.

• Seis obligaciones sobreviven al prototipo: evaluación continua, detección de deriva, registro de modificaciones, documentación de riesgo del modelo, cambios regulatorios y soporte técnico de guardia. Comprar transfiere algunas de ellas. Nunca las transfiere todas.

• La obligación que más a menudo decide la balanza es la evaluación independiente. Si desarrolla el agente, el equipo que lo creó no puede ser también el que lo evalúe de manera objetiva.

• Desarrollar es la respuesta correcta más a menudo de lo que admite la página de un proveedor, y la objeción de la dependencia del proveedor al comprar es un problema real, no un mero trámite de compras.

• Esta página no incluye cifras de costes en ningún sentido, porque no existe ninguna que sea justificable. Cada afirmación sobre costes aquí es estructural: defina la obligación y luego identifique quién es el responsable de ella.

Quien más se opone al desarrollo propio, tiene la capacidad de hacerlo

El argumento más contundente en contra de desarrollar un agente de riesgo interno que hemos escuchado este año provino de un director de gestión de fraude en una empresa global de pagos, cuyo equipo se dedica profesionalmente a crear su propia infraestructura de datos.

Cuando sus colegas lo presionan para desarrollar, él se resiste. «Intentan convencerme de que queremos construirlo y yo hago todo lo posible por convencerlos de lo contrario», afirmó, «porque somos muy buenos en ciertas cosas. Por ejemplo, somos excelentes moviendo datos, a eso nos dedicamos. Movemos dinero, que no son más que datos, API, orquestaciones y todo eso. Es decir, desarrollamos ese tipo de soluciones todo el tiempo para todas nuestras áreas».

Su objeción es de competencia, no de capacidad. Sabe perfectamente en qué es bueno su equipo y qué queda fuera de su alcance. Y de hecho, sí desarrolló algo: la estructura de fraude que gestiona hoy en día es una capa de orquestación diseñada por su propio equipo, y funciona. La mayor parte de lo que sigue proviene de su experiencia, porque un desarrollo propio que funciona enseña mucho más sobre el coste real de creación que uno que ha fracasado.

Qué significa desarrollar frente a comprar específicamente para un agente de riesgo

¿Debería un banco desarrollar o comprar agentes de riesgo de IA? Desarrollar significa asumir el control del agente y todo lo que viene después: el programa de evaluación, el monitoreo, el registro de modificaciones, la documentación del modelo, los turnos de guardia y la explicación que se le da a un inspector cuando pregunta por qué se tomó una decisión. Comprar significa transferir algunas de estas obligaciones a un proveedor y quedarse con el resto, sabiendo que ningún proveedor las asume todas. La versión regulada de esta decisión no es si sus ingenieros podrían construirlo, sino qué persona concreta asumirá cada obligación dentro de tres años y si todavía podrá responder por ella.

Este enfoque es importante porque la versión empresarial genérica del dilema entre comprar o desarrollar, redactada para una herramienta de procesamiento de documentos o un asistente de atención al cliente, se limita al coste de desarrollo y al tiempo de comercialización. Un agente de riesgo forma parte de una decisión que su institución debe justificar. El coste determinante es el de defender esa decisión repetidamente, durante años, bajo un marco regulatorio que aún se está escribiendo.

Hay un aspecto que queda fuera de este análisis de forma deliberada. El criterio y la medición para evaluar un agente es una pregunta previa y un tema aparte: consulte cómo evaluar un agente de riesgo de IA. Esta página asume que usted ya sabe qué define a un buen sistema y que solo está decidiendo quién lo construye.

Lo que el prototipo no le muestra

Un prototipo demuestra que un agente puede generar una buena recomendación una vez. El entorno de producción plantea si seguirá generando una buena recomendación dentro de dieciocho meses y si usted podrá justificar el proceso. En ese punto surgen seis obligaciones que no se ven en una demostración.

Evaluación continua. La evaluación que validó el prototipo fue una prueba única con una muestra seleccionada. La evaluación en producción es un programa permanente con un responsable, una frecuencia establecida, un conjunto de datos de prueba que sigue siendo representativo a medida que cambia el tráfico y un registro de cada resultado.

Detección de deriva. Los patrones de fraude cambian, su base de clientes evoluciona y un agente ajustado con las alertas del año pasado deja de estar optimizado silenciosamente. Detectar esto es una tarea; decidir qué pasa cuando salta la alarma y quién está autorizado a pausar el agente es otra mucho más difícil. Hemos detallado este proceso técnico en monitoreo de agentes de IA para detectar deriva.

Registro de modificaciones. Cuando un analista no está de acuerdo con el agente y cambia la resolución, esa discrepancia es la señal más valiosa que genera el sistema. Sin embargo, solo es útil si se registra como un evento con un motivo justificado. Si se guarda simplemente editando un campo de texto, se habrá perdido la señal.

Documentación de riesgo del modelo. Historial de versiones, decisiones de entrenamiento, resultados de evaluación, limitaciones conocidas y la justificación de cada cambio. La prueba de fuego es si la documentación sigue respondiendo a las dudas una vez que el ingeniero que construyó el agente se ha ido.

Cambios regulatorios. El 17 de abril de 2026, la Reserva Federal, la FDIC y la OCC publicaron de forma conjunta una guía revisada sobre la gestión de riesgos de modelos (difundida como SR 26-2 en la Reserva Federal, Boletín 2026-13 en la OCC y FIL-15-2026 en la FDIC). La carta de la Fed establece que esta «supera y reemplaza la carta SR 11-7» y la declaración interinstitucional de 2021 sobre el riesgo de modelos para sistemas BSA/AML. Cualquier elemento en su documentación de gobernanza que aún cite las cartas antiguas debe reescribirse. Las agencias también han avanzado que planean solicitar información sobre el uso de la IA en los bancos, algo que aún no se ha publicado, pero que volverá a cambiar las reglas del juego cuando aparezca.

Soporte técnico de guardia. Un agente que trabaja en una cola de alertas en tiempo real es infraestructura de producción. El teléfono de alguien sonará a las 3 de la mañana si el sistema deja de responder, y esa persona debe conocer tanto el sistema como las consecuencias de riesgo de dejarlo inactivo.

A continuación, se muestra esta lista en forma de tabla de decisiones. El ejercicio útil no es leerla, sino escribir el nombre de una persona de su propia organización en cada casilla.

Ninguna casilla de esta tabla queda vacía en ninguna de las dos opciones. Ese es el argumento principal.

La obligación decisiva: evaluación independiente

La guía revisada mantiene el concepto de evaluación efectiva y especifica quién puede realizarla. El documento SR 26-2 la define como «el análisis crítico realizado por expertos objetivos que evalúan el riesgo del modelo e introducen los cambios adecuados a lo largo de su ciclo de vida», llevado a cabo por «personas con la experiencia adecuada para realizar una evaluación crítica y objetiva, con la suficiente independencia para mantener la objetividad, así como con la posición organizativa y la influencia necesarias para aplicar cualquier cambio».

Piense en esto como tres condiciones: experiencia, independencia y autoridad para cambiar las cosas. Luego, aplíquelo a un desarrollo propio. Las personas que conocen el agente lo suficiente como para evaluarlo son las mismas que lo crearon, por lo que no cumplen con la condición de independencia. Por tanto, desarrollar un agente implica dotar de personal tanto al equipo de desarrollo como al de evaluación independiente, con diferentes líneas de reporte, con la experiencia necesaria para debatir con los desarrolladores y la autoridad suficiente para detenerlos. Comprar no elimina esta obligación, pero sitúa la experiencia y la independencia en organizaciones distintas de forma predeterminada, lo cual es mucho más fácil de demostrar ante una auditoría.

Conviene hacer dos precisiones, ya que este argumento no debe exagerarse. La guía revisada deja fuera de su alcance la IA generativa y la agéntica: el boletín de la OCC señala que «los modelos de IA generativa e IA agéntica son novedosos y evolucionan rápidamente. Por lo tanto, no entran en el ámbito de aplicación de esta guía», y el SR 26-2 confirma que los principios se aplican a «modelos estadísticos y cuantitativos tradicionales y modelos de IA no generativos y no agénticos». La evaluación efectiva es, por tanto, un criterio de referencia útil que conviene adoptar, no una regla de obligado cumplimiento para su agente. La guía también indica que «se prevé que sea más relevante para organizaciones bancarias con activos totales superiores a 30 000 millones de dólares», y que sea más relevante para no significa que se aplique exclusivamente a ellas.

La revisión también redujo la definición de modelo a «un método, sistema o enfoque cuantitativo complejo que aplica teorías estadísticas, económicas o financieras para procesar datos de entrada y obtener estimaciones cuantitativas». Una función de riesgo que combine un motor de reglas, un modelo de scoring y un agente tiene ahora tres componentes situados en tres puntos diferentes respecto a un único marco de trabajo. No puede asumir que un solo sistema de gobernanza cubre los tres, y ese trabajo de estructuración recaerá sobre usted, independientemente de quién haya programado el código. Puede consultar nuestro análisis detallado sobre gobernanza en gobernanza de agentes de riesgo de IA.

Lo que cuesta realmente desarrollar, según la experiencia de quien lo ha hecho

Al preguntarle qué tan difícil fue la orquestación interna, la respuesta del director de fraude fue directa: «es más complejo de lo que esperaba».

Detalló con precisión dónde radica la dificultad, y no es en el modelo. «El reto es el enriquecimiento dentro de esa capa de orquestación, por el volumen de trabajo que requiere unificar los datos de múltiples fuentes en una única plataforma de decisión. Así que definitivamente hay dificultades ahí». Y añadió una reflexión que conviene citar textualmente, ya que representa una opinión honesta y no una historia de fracaso: «No hay nada que no pueda solucionarse con recursos y tiempo, pero son dos cosas difíciles de conseguir».

Esa es la realidad del coste de desarrollo de agentes de IA en un área de riesgo. No es algo imposible, sino una demanda constante de dos recursos que siempre escasean frente a una carga de trabajo que no disminuye. Si le pregunta cuándo estará terminado el sistema unificado, responde con una broma que oculta una cifra real: «Hay un punto único de conexión para todos nuestros procesos internos al que, espero que antes de que me jubile, todo el mundo esté conectado. Porque somos una gran empresa y, francamente, crecemos a base de adquisiciones. Así que probablemente tengamos unas 30 plataformas diferentes en lista de espera para integrarse en el sistema unificado de fraude».

Comprar tampoco le exime del trabajo de datos. Un director de I+D en una plataforma global de pagos, al enumerar las tareas pendientes más importantes en una implementación activa, situó la carga de datos históricos en segundo lugar: «La carga de datos históricos, que es más una tarea estratégica que táctica por el momento». Un agente que analiza la relación con un cliente necesita el historial de esa relación, y transferir esa información es un trabajo estratégico se elija la opción que se elija.

Nota sobre el coste total de propiedad. Esta página no incluye cifras de costes en ningún sentido. No existe un número justificable que podamos publicar sobre lo que cuesta desarrollar o mantener un agente de riesgo interno, y no vamos a inventar una estimación. Si un proveedor le presenta un modelo de coste total de propiedad de IA para tomar esta decisión, pregúntele de dónde procede cada dato y contra qué se ha medido. La mayoría de estos modelos se diseñan de atrás hacia delante para obtener el resultado que el autor desea mostrar.

Cuándo tiene sentido desarrollar

Desarrollar suele ser la decisión correcta, y hay cinco situaciones en las que resulta evidente.

El agente es el producto en sí o es inseparable de él. Si su lógica de riesgo es lo que compran los clientes o lo que hace que su modelo de precios funcione, externalizarla equivale a externalizar su margen de beneficio.

Ya gestiona bien la capa de datos y el agente es un añadido sencillo. Esta es la postura del director de fraude, y es el argumento más sólido a favor del desarrollo propio. La parte costosa de un agente de riesgo es conseguir datos limpios, enriquecidos y actualizados en un solo lugar para poder analizarlos. Si ya ha asumido ese coste, el trabajo restante es realmente menor, y pagar a un proveedor para resolver un problema ya solucionado es un gasto innecesario.

La concentración de proveedores es en sí misma el riesgo que está gestionando. Si una parte sustancial de sus decisiones de riesgo ya pasa por un único proveedor externo, añadir otra dependencia al mismo proveedor es una decisión de riesgo de concentración antes que tecnológica, y debe ser evaluada por el responsable de riesgos de terceros.

Ningún producto se adapta a su flujo de trabajo y la brecha es estructural. Los productos inusuales, los entornos regulatorios atípicos y los procesos de cliente poco comunes generan requisitos que las soluciones estándar de los proveedores no cubrirán. La prueba consiste en ver si el problema es una función que falta o un diseño estructural diferente. Una función que falta se puede negociar; un diseño estructural diferente requiere un desarrollo propio.

Puede dotar de personal al equipo de evaluación de forma independiente al de desarrollo. Si no puede hacerlo, no está eligiendo entre desarrollar y comprar. Está eligiendo entre un desarrollo propio que puede justificar y defender, y uno que no.

La objeción de la dependencia del proveedor, sin filtros

El argumento más sólido contra la compra provino del mismo director de fraude, y merece la pena leerlo con sus propias palabras en lugar de resumirlo.

«Analizo el riesgo más allá del fraude. También tengo que considerar el riesgo de proveedores y la exposición al mercado. Desde mi punto de vista, era fundamental que mantuviéramos el control sobre los puntos de conexión reales y que ningún proveedor se implementara de manera que no pudiera ser reemplazado. Si vincula sus sistemas a un solo proveedor, se queda sin margen de maniobra. No hay alternativa. Se acaba atrapado en una especie de matrimonio no deseado con un socio externo».

Al preguntarle directamente qué opinaría su empresa de adoptar una plataforma como la nuestra, no lo suavizó: «Desde el punto de vista del negocio, es simplemente un movimiento de alto riesgo».

Tiene razón, y la respuesta honesta no es rebatirlo, sino plantear una prueba que debe incluir en el contrato antes de firmarlo. ¿Cómo es el proceso de salida? ¿Puede recuperar sus datos, su historial de evaluación y su registro de modificaciones en un formato útil, por iniciativa propia y sin contratar servicios profesionales adicionales? ¿Los puntos de conexión son suyos, de modo que sustituir un componente no implique cambiar toda la estructura tecnológica? ¿Existe una obligación contractual explícita de devolver la documentación del modelo? Un proveedor que no pueda responder a estas preguntas por escrito es exactamente el proveedor que él describe.

La solución estructural es que una capa de agentes no tiene por qué situarse por debajo de todo el sistema. Los agentes de Oscilar pueden ejecutarse dentro de la plataforma completa o como una capa independiente sobre su tecnología actual, lo que mantiene la orquestación y los puntos de conexión exactamente donde ya están. Esto no elimina el riesgo de proveedor, pero cambia el coste de sustituirlo, que es precisamente lo que él busca proteger.

La solución híbrida: lo que la mayoría de las instituciones hacen realmente

La mayoría de los equipos de riesgo regulados no eligen estrictamente entre comprar o desarrollar. Se quedan en un punto intermedio, y las integraciones exitosas comparten una característica: la división sigue las obligaciones y responsabilidades, no el organigrama.

Suelen darse tres modelos. Comprar la capa de análisis y conservar los puntos de conexión, que es muy similar a lo que el director de fraude desarrolló, con la diferencia de que la capa superior de la orquestación se adquiere en lugar de programarse de forma interna. Comprar para un proceso estándar y desarrollar para el flujo de trabajo exclusivo, lo cual funciona cuando una parte de la actividad es realmente inusual y el resto no. Comprar la plataforma y desarrollar la evaluación, lo que mantiene dentro de la institución el control sobre si el agente está funcionando correctamente.

El modelo híbrido no es gratuito. Dos sistemas de gobernanza implican dos conjuntos de documentación, dos frecuencias de evaluación y un límite de responsabilidad que alguien debe definir de forma explícita. Los límites confusos son el origen de las incidencias. Lo que hace que un modelo híbrido sea justificable, y no solo cómodo, es que se pueda identificar claramente para cada obligación de la tabla anterior de qué lado de la línea se sitúa y por qué.

Cómo estructurar la decisión

El mejor método que hemos visto no se basaba en una matriz de evaluación ponderada. El responsable de evaluar la opción de desarrollar frente a comprar para el área de crédito y cobros en una empresa de servicios financieros digitales lo organizó en tres documentos:

1. Una especificación para el desarrollo propio. «Un documento de requisitos o especificaciones de lo que necesitaríamos para que nuestras herramientas internas funcionen y cumplan con las necesidades específicas que tenemos».

2. Un análisis comparativo. «Todo lo que ya ofrecen listo para usar los distintos proveedores», contrastado con esos mismos requisitos.

3. Una comparativa de recursos. «¿Cuántos recursos internos necesitamos para desarrollar todo lo que está en nuestra lista de deseos frente a cuánto nos costará firmar un contrato e integrar a un proveedor que ya tiene todo esto desarrollado?»

Y aquí la reflexión que debería cambiar su enfoque de planificación sobre la comparativa de costes: «No creo que ese debate sea difícil de resolver. Lo complicado es justificar por qué, si ya tenemos 20 herramientas diferentes, necesitamos la número 21».

El análisis de costes es la parte sencilla. Lo difícil es la consolidación. Si defiende la opción de comprar, la mayor parte de su preparación debe centrarse en explicar por qué esto no añade otra herramienta aislada: qué herramientas actuales sustituye o absorbe, en qué pantalla de trabajo aparecerá y cómo cambiará el día a día del analista tras su adopción. Una propuesta de compra que solo se justifique por el precio perderá frente a la objeción de la «herramienta número 21», y con razón.

Dos aspectos más a tener en cuenta. El proceso de evaluación al comprar tiene una estructura clara que puede exigir a cualquier proveedor, y es una buena prueba para saber si tienen experiencia real: configuración de datos, una prueba retrospectiva (backtest) con sus alertas históricas, una fase de ejecución en paralelo (shadow-mode) junto a sus analistas y una presentación humana de los resultados antes de pasar a producción. Exija estas cuatro fases de forma explícita. Por otra parte, tenga claro a quién va dirigido el documento. En la misma reunión: «Nuestro equipo de proyecto defiende la compra frente al desarrollo propio. Solo necesitamos que los directivos clave se alineen con esta recomendación». El equipo técnico suele tenerlo claro desde el principio; lo que necesitan son argumentos sólidos para la revisión de la dirección, lo que requiere un enfoque diferente al de un marco de decisión técnica.

Dónde falla este planteamiento

Cuatro limitaciones a todo lo expuesto anteriormente.

Esta página no contiene cifras de costes. Es una limitación real, no una postura de modestia. Cualquier análisis de desarrollo frente a compra necesita números en última instancia, y estos deberán proceder de su propio modelo de recursos, no de un artículo de internet.

El único resultado medible que podemos aportar es acotado. Un banco en fase de implementación muestra un 92 % de coincidencia del agente con su equipo de analistas en la resolución de alertas y un 75 % menos de tiempo dedicado por revisión. Se trata de una única implementación en un área de riesgo concreta y no es un parámetro de referencia que otra institución deba esperar replicar exactamente.

Ninguna de las dos opciones responde a la pregunta previa. Decidir qué significa que sus agentes «funcionen correctamente» y qué métricas lo demostrarían es una tarea anterior a la decisión de comprar o desarrollar, y no se simplifica elija lo que elija.

Desarrollar frente a comprar tampoco es una situación permanente. Las fronteras cambian a medida que su estructura de datos madura, se lanzan nuevos productos o el personal rota. Plantee la decisión como reversible y diseñe el proceso de salida en consecuencia, sea cual sea el camino que elija.

Preguntas frecuentes

¿Debería un banco desarrollar o comprar agentes de riesgo de IA?

Desarrolle cuando el agente sea inseparable de su producto, cuando su capa de datos ya sea tan sólida que el agente sea un añadido sencillo, cuando la concentración de proveedores sea en sí misma un riesgo que deba gestionar o cuando ningún producto se adapte a un flujo de trabajo estructuralmente inusual. Compre cuando necesite una evaluación, supervisión y documentación listas para producción más rápido de lo que puede dotar de personal a esos procesos, y especialmente cuando no disponga de recursos para un equipo de evaluación independiente del equipo de desarrollo. En cualquier caso, las obligaciones normativas persisten.

¿Cómo se evalúa la opción de desarrollar frente a comprar para una solución de IA?

Redacte tres documentos: una especificación de lo que requeriría el desarrollo propio, un análisis comparativo de lo que cada proveedor ofrece listo para usar frente a esos mismos requisitos y una comparación directa de recursos necesarios. Después, responda a la cuestión de la consolidación por separado, ya que una propuesta de compra basada únicamente en costes perderá ante la objeción de que ya cuenta con demasiadas herramientas.

¿Cuándo debería un equipo desarrollar un agente de IA en lugar de comprarlo?

Desarrolle cuando ya tenga resuelta la parte más compleja. El trabajo costoso en un agente de riesgo es el enriquecimiento y la unificación de datos de múltiples fuentes en una sola plataforma de decisión; un equipo que ya ha solucionado esto pagará muy poco si desarrolla la capa de análisis por encima. Desarrolle también cuando la diferencia entre sus requisitos y los productos disponibles en el mercado sea estructural y no una función pendiente de desarrollo.

¿Cuánto cuesta desarrollar internamente un agente de riesgo de IA?

No hay cifras públicas fiables y esta página no ofrece ninguna. Los profesionales describen en su lugar la naturaleza del coste: enriquecimiento de datos de múltiples fuentes, una lista de tareas pendientes de la plataforma que no disminuye y una demanda constante de tiempo de ingeniería. Un director de fraude que desarrolló una capa de orquestación interna operativa estimó la fecha de finalización para conectar todo en «espero que antes de que me jubile».

¿Qué se debe mantener una vez que el prototipo funciona?

Seis elementos: evaluación continua, detección de deriva con una política de respuesta, registro de modificaciones como evento estructurado, documentación de riesgo del modelo que sobreviva a su autor, seguimiento de cambios regulatorios y turnos de soporte técnico de guardia. Ninguno de ellos se aprecia en una demostración, y todos requieren un responsable desde el primer día que el agente entra en producción.

¿Quién es el propietario de la documentación de riesgo del modelo si desarrollamos el agente nosotros mismos?

Usted, por completo, lo que incluye el historial de versiones, los resultados de evaluación, las limitaciones conocidas y la justificación de cada cambio. Si decide comprar, el proveedor facilita el registro del modelo y usted gestiona cómo se adapta a su propio marco de trabajo. La prueba en ambos casos es si la documentación sigue respondiendo a las preguntas de un auditor una vez que la persona que la redactó ha dejado la empresa.

¿Puede un agente de riesgo de IA adquirido integrarse con los sistemas de riesgo existentes de una institución?

Sí, y es un aspecto que conviene confirmar explícitamente antes de firmar cualquier contrato. Los agentes de Oscilar pueden funcionar como una capa independiente sobre la infraestructura que ya posee, o como parte de nuestra plataforma unificada, por lo que comprar un agente no exige sustituir su orquestación ni sus proveedores actuales. La pregunta clave para cualquier proveedor es si los puntos de conexión seguirán estando bajo su control.

¿Cómo se gestionan la revisión humana, la auditabilidad y el rendimiento del agente en cada opción?

En ambas opciones, la institución es la responsable de la gobernanza. La postura de Oscilar es que los agentes nunca cierran ni escalan alertas de forma autónoma; cada recomendación es revisada y validada por un analista humano antes de tomar cualquier medida, con un registro de auditoría completo que muestra los datos de entrada, el análisis del agente y el resultado final. Si opta por desarrollar, deberá crear ese registro equivalente usted mismo, detallando exactamente dónde intervienen las personas en la toma de decisiones.

Por dónde empezar

Tome la tabla de obligaciones anterior y escriba el nombre de una persona en cada celda para ambas columnas en el contexto de su propia institución. Este ejercicio requiere una tarde y suele resolver el debate, ya que una de las columnas suele presentar casillas que nadie puede cubrir. Esa será su respuesta, y será mucho más honesta que cualquier modelo de simulación de costes.

Dos pasos siguientes. Si aún no tiene claro contra qué va a medir el rendimiento del agente, esa pregunta debe resolverse primero y se analiza de forma independiente. Asimismo, definir qué límites debe superar una prueba piloto antes de ser aceptada es una decisión propia que abordaremos en un artículo complementario.

Si la columna de compra es la que presenta dudas, la forma más rápida de resolverlas es pedir a un proveedor que ejecute las cuatro fases con sus propios datos: configuración de datos, prueba retrospectiva con sus alertas históricas, fase de ejecución en paralelo y análisis de resultados con su equipo. Vea cómo los agentes de riesgo de Oscilar están diseñados para trabajar junto a los analistas y sistemas que ya tiene implementados, y presente la tabla de obligaciones en su primera conversación.