Guía de compra de software de prevención de lavado de dinero para instituciones financieras: qué saber antes de cambiar de proveedor

Última actualización: septiembre de 2026

Comprar un software de prevención de lavado de dinero (AML) es, en gran medida, un proyecto de transición. La demostración muestra lo que un nuevo sistema puede detectar, pero el riesgo real está en migrar un programa de cumplimiento activo hacia él sin perder su historial ni su buena reputación ante los inspectores. Esta guía de compra de software de AML cubre las cinco decisiones que debe resolver antes de firmar: las pruebas regulatorias que debe solicitar, qué historial se migra, cómo funcionarán ambos sistemas en paralelo, quién validará el nuevo sistema y cómo mantener informados a los inspectores. Un proveedor que no pueda ayudarle con estos cinco puntos no está listo para que lo contraten.

Resumen rápido

• La mayor parte del riesgo al comprar un software de AML radica en la transición misma; una elección incorrecta significa tener que migrar dos veces.

• Solicite las pruebas que ya tiene el proveedor actual: historial de auditorías en instituciones similares, validaciones independientes y acceso de los validadores a la lógica del sistema y a sus datos.

• Haga un inventario del historial que solo vive en el sistema antiguo, decida qué se migra y qué se conserva por cuestiones de retención de registros, y asuma que nada se transfiere de manera idéntica.

• Una ejecución en paralelo compara los resultados; la validación comprueba los datos y el método. Los criterios de salida acordados de antemano deciden cuándo finaliza esta fase.

• Encargue su propia validación independiente, revise ambos sistemas durante el período retrospectivo e informe a los inspectores antes de dar de baja el sistema antiguo.

Las cinco decisiones que determinan el éxito o fracaso al comprar un software de AML

La compra de un software de AML depende de cinco decisiones que se deben tomar antes de firmar el contrato: qué pruebas regulatorias puede ofrecer el proveedor, qué historial se migra, cómo funcionarán el sistema antiguo y el nuevo en paralelo (y cuándo termina esa fase), quién validará el nuevo sistema y cuándo se informará a los inspectores sobre el cambio. Ninguno de estos puntos se muestra en una demostración, y cada uno genera un documento que un inspector podría solicitar.

Una decisión se considera tomada solo cuando existe el documento de la última columna.

Una elección equivocada significa una segunda transición. El director de cumplimiento normativo de una empresa de pagos comentó: "No quiero dar un salto para luego tener que migrar otra vez... porque elegimos la opción incorrecta". Un oficial de control de calidad de BSA en un banco corporativo describió el cambio de proveedores como "un camino increíblemente largo".

Esta guía cubre el proceso de compra después de la lista de candidatos y la evaluación. La elaboración de la lista, según el tipo de producto y los criterios que revelan los proveedores, se analiza en una guía independiente para comparar software de monitoreo de transacciones. La forma de probar esa lista con sus propios datos, evaluando la calidad de las alertas y el flujo de trabajo en conjunto, se cubre en una guía para evaluar plataformas de monitoreo de transacciones de AML.

Por qué comprar un software de AML es, en realidad, un proyecto de transición

Comprar un software de BSA/AML es un proyecto de transición porque el proveedor actual tiene ventajas que el nuevo sistema debe ganarse. Los inspectores ya lo conocen, y los contratos, el presupuesto y la configuración de la institución están diseñados en torno a él. Un responsable de cumplimiento de BSA/AML en un banco comunitario describió lo que vende un sistema consolidado: "En el mundo de los inspectores, ya ha sido aprobado. Así que... pueden cuestionar si ajustas esto o aquello. Pero no cuestionan el sistema en sí. Al final del día, pagas por eso, pagas por la tranquilidad".

La transición comienza en el calendario de contratos. Un vicepresidente y oficial de riesgo de AML en un banco comunitario de negocios prefirió no evaluar alternativas porque el contrato actual se acababa de renovar; mencionó que recibir propuestas antes de la renovación habría sido oportuno. Además, es posible que el presupuesto no dependa de cumplimiento: un director de operaciones contra delitos financieros en un gran banco regional señaló que "el área de tecnología es dueña de nuestro presupuesto". Identifique las fechas de renovación y al responsable del presupuesto antes de iniciar la evaluación.

Un comprador que ya ha pasado por una implementación fallida querrá pruebas primero. Un responsable que gestionaba contratos y la exposición regulatoria para una compra comentó que su equipo no quería repetir "la última experiencia en la que compramos una herramienta, avanzamos con la implementación y luego nos dimos cuenta de que había cosas que simplemente no podíamos hacer".

Una transición también requiere más aprobaciones de las que sugiere una demostración. Un oficial de BSA/AML y OFAC en un banco regional mencionó la necesidad de aprobación de "nuestro grupo de gestión de riesgo empresarial, nuestro grupo de datos, TI, seguridad de la información... y gestión de riesgo de modelos". En el caso de una fintech, hay un aprobador adicional, ya que, como señaló un responsable de riesgo y cumplimiento en una fintech de consumo, "Nuestro banco patrocinador nos exige aprobar a cada uno de los proveedores que utilizamos". Redacte la evaluación para que cada uno de estos grupos pueda revisarla e involucre al banco patrocinador desde el inicio.

La decisión de desarrollar una solución propia en lugar de comprarla se analiza en una guía independiente sobre desarrollo propio frente a la compra de agentes de IA en operaciones de riesgo reguladas.

Las pruebas regulatorias que debe solicitar a un proveedor

Las pruebas regulatorias que debe pedir a un proveedor de software de AML son las mismas evidencias que ya tiene su proveedor actual: historial de auditorías en instituciones similares a la suya, validaciones realizadas por terceros independientes y la garantía de que sus propios validadores puedan ver y probar el funcionamiento del sistema. Un responsable de cumplimiento de BSA/AML en un banco comunitario destacó las dos primeras: "que algunos bancos respalden que pasaron por una auditoría usando ese sistema como registro oficial y salieron bien, o validaciones del sistema hechas por terceros como auditores independientes".

Pregunte qué recibirán sus validadores, ya que necesitan tanto la lógica del sistema como los datos de la institución. Un gerente de BSA en una cooperativa de crédito describió cómo los validadores externos de modelos pidieron extracciones de datos al proveedor actual y este les respondió que no podía entregarlas: "¿cómo es posible que no podamos obtener extracciones de nuestros propios datos?". Asegúrese de incluir en el contrato el acceso a la lógica, la posibilidad de realizar consultas de datos y la entrega de extracciones de datos completas.

El modelo del proveedor sigue siendo responsabilidad de la institución para su validación. La guía de gestión de riesgo de modelos SR 26-2 (emitida por la Reserva Federal junto con el Boletín OCC 2026-13 y FDIC FIL-15-2026 el 17 de abril de 2026) señala que las organizaciones bancarias "podrían no recibir del proveedor el código subyacente, los datos o la metodología", pero "los principios de gestión de riesgo de modelos siguen vigentes". La guía señala "la validación de los productos del proveedor, ya sea por parte de equipos internos o externos" como un elemento fundamental.

La debida diligencia de terceros es el escenario donde se pone a prueba el entendimiento que la institución tiene del sistema. Por lo tanto, involucre desde la evaluación a la persona que tendrá que defenderlo ante los inspectores. Un gerente de producto en un banco patrocinador le dijo a un proveedor: "No tienes que convencerme. Lo entiendo, pero yo no soy quien debe defenderlo ante los inspectores". Cómo evaluar las afirmaciones de un proveedor sobre su IA es un tema aparte que se cubre en la guía para evaluar plataformas de riesgo de AML impulsadas por IA.

Qué historial se migra al nuevo sistema y qué se queda atrás

El historial que solo vive en el sistema de monitoreo antiguo, como los registros de SAR y CTR, los archivos de alertas y casos, y los modelos integrados en él, debe planificarse antes de firmar. De lo contrario, cualquier información que no pueda migrarse obligará a mantener el sistema antiguo activo para cumplir con la retención de registros. Un analista de BSA y fraude en un banco comunitario con un programa de banca asociada describió lo que se debe extraer: "Habrá cosas que extraigamos [del proveedor actual] que no estarán en nuestro núcleo central, como los SAR, CTR y ese tipo de información".

Cuando el historial no se puede migrar, el sistema antiguo debe seguir funcionando: un responsable de control de calidad en un administrador de programas de tarjetas prepagadas comentó que una instancia local del proveedor anterior seguía activa solo para retención de registros porque su historial no se podía migrar a la nueva versión, y que lo que sí se migró se hizo de forma manual, "algo que me gustaría evitar si tengo que hacerlo de nuevo". Los modelos también pueden quedarse atrás. Un líder de operaciones en un banco patrocinador mencionó que el modelo de calificación de riesgo de clientes del banco funciona dentro de su sistema de monitoreo actual y se valida allí.

El trabajo de datos comienza antes, en el sistema bancario central, donde un gerente de proyecto en un banco de bancos anticipaba "una gran cantidad de mapeo de datos". La lógica de las reglas requiere el mismo inventario; un oficial de BSA en un banco comunitario con un programa de banca asociada comentó: "[El proveedor actual] no nos da la lógica de las reglas". Las reglas que nadie puede ver no se pueden transferir ni comparar.

Antes de firmar, haga un inventario de al menos:

• El historial de SAR y CTR, incluyendo los motivos documentados detrás de cada decisión de presentar o no un informe.

• Los archivos de alertas y casos, con sus resoluciones y las pruebas recopiladas.

• Las calificaciones de riesgo de los clientes y los modelos que las generan, junto con su validación.

• Las configuraciones de reglas y escenarios, con la documentación que justifica cada umbral.

• La pista de auditoría de quién cambió qué, y cuándo.

No asuma que cualquier proveedor migrará el historial de SAR y casos de manera idéntica. Pregunte qué se migra, en qué formato, qué permanecerá legible en el sistema antiguo y cómo se conciliarán ambos para garantizar que no se pierda ninguna alerta o caso.

Cómo ejecutar el sistema antiguo y el nuevo en paralelo

Una ejecución en paralelo mantiene funcionando el sistema antiguo y el nuevo de AML con la misma actividad al mismo tiempo, lo que permite comparar sus resultados antes de apagar el sistema anterior. La ejecución en paralelo no es una validación: compara resultados, mientras que la validación comprueba la integridad de los datos que ingresan al nuevo sistema y el método que este aplica. Un director de asesoría de riesgos en una consultora explicó la diferencia durante una transición: "La ejecución en paralelo no es realmente la validación; eso es análisis de alertas, revisión y comparación de resultados. La validación se centra en los datos, en asegurar que validamos los datos de origen en [el nuevo sistema], controlamos su calidad y hacemos la conciliación".

Desactive el sistema antiguo únicamente cuando ambas columnas estén completas, ya que una no reemplaza a la otra.

Realice una prueba en paralelo incluso si el sistema antiguo es sencillo, porque la institución debe poder demostrar que se hizo. Como comentó el director de cumplimiento de un banco comunitario: "Desde la perspectiva del regulador, queremos poder decir que hicimos [una ejecución en paralelo]".

Cómo diseñar la ejecución en paralelo

1. Acuerde los criterios de salida antes de empezar. Documente qué diferencias deben explicarse, qué se considera una explicación válida y quién aprueba los resultados. La prueba termina cuando se cumplen estos criterios.

2. Compare resultados y anticipe que el número de alertas variará. Un sistema con una arquitectura diferente no generará las mismas alertas; un responsable de implementación en una empresa de pagos internacionales B2B señaló que comparar la cantidad de alertas es como "comparar peras con manzanas". Intentar igualar a un proveedor con debilidades conocidas no aportaría mucho valor.

3. Concilie la información que pasa de un sistema a otro. Los resultados pueden variar, pero ninguna transacción, alerta o caso que deba llegar al nuevo sistema puede perderse.

4. Evite duplicar el trabajo de los investigadores. Un subdirector de estrategia de riesgo de cumplimiento en un banco regional buscaba "una prueba en paralelo con lo que tenemos hoy y el nuevo sistema sin duplicar las alertas". Decida de antemano con las alertas de qué sistema trabajarán los analistas.

5. Explique cada diferencia por escrito, en ambas direcciones: qué detectó el nuevo sistema que el antiguo pasó por alto, y cuál es la solución para cualquier omisión.

La declaración conjunta sobre innovación de 2018 (vigente a septiembre de 2026) respalda este tipo de pruebas. Señala que los programas piloto ejecutados junto a procesos existentes son "un medio importante para probar y validar la eficacia de enfoques innovadores" y aclara que, cuando un sistema de monitoreo basado en IA detecta actividad sospechosa que los procesos anteriores omitieron, "las agencias no asumirán automáticamente que los procesos anteriores del banco eran deficientes". La declaración deja los tiempos en manos de la administración, que debe evaluar "si los enfoques innovadores están lo suficientemente maduros para reemplazar o complementar los procesos de BSA/AML actuales y en qué momento".

Por lo tanto, el tiempo de convivencia de ambos sistemas depende de los criterios de salida. Un responsable de cumplimiento de BSA/AML en un banco comunitario describió la balanza: "Cuanto más tiempo ejecutes ambos sistemas, más cómodo te sentirás con el nuevo. Pero, por supuesto, mantener ambos tiene un costo". El comprador y el proveedor también pueden tener expectativas de tiempo distintas; un oficial de BSA en un banco de bancos estimó que las pruebas en paralelo durarían más de lo previsto por el proveedor. Definir los criterios antes de firmar resuelve esto con datos.

Validar el nuevo sistema antes de retirar el antiguo

Antes de retirar el sistema antiguo, el nuevo debe someterse a una validación independiente. El manual de inspección de BSA/AML del FFIEC señala que "la metodología de programación y la efectividad de un sistema de monitoreo deben validarse de forma independiente para garantizar que los modelos detecten actividades potencialmente sospechosas", y que la administración "debe documentar y ser capaz de explicar los criterios de filtrado y los umbrales utilizados, y por qué son adecuados para los riesgos del banco".

La validación durante la transición analiza ambas direcciones, como describió un gerente de cumplimiento regulatorio en una firma de auditoría de BSA y validación de modelos: "Tuvimos que asegurarnos de que el sistema antiguo estuviera generando las alertas correctas, pasarlas por el nuevo sistema y confirmar que el nuevo no omitiera nada".

La validación del proveedor no reemplaza a la de la propia institución. Un oficial de BSA en un banco comunitario que encargó una validación independiente tras implementar un nuevo sistema comentó: "Obviamente ellos te entregan una validación del modelo, pero nosotros hicimos una aparte... Fue la mejor decisión que tomamos... porque aprendimos muchísimo". Una validación es un proceso de revisión, no una certificación: su entregable es un resumen del trabajo realizado.

Determinar si un escenario se clasifica como un modelo bajo la norma SR 26-2 es una decisión que debe documentarse. La guía, que reemplazó a las normas SR 11-7 y SR 21-8 y sigue vigente a septiembre de 2026, define un modelo como "un método, sistema o enfoque cuantitativo complejo que aplica teorías estadísticas, económicas o financieras para procesar datos de entrada y generar estimaciones cuantitativas". Excluye los "procesos basados en reglas deterministas y software que no tengan teorías estadísticas, económicas o financieras que sustenten su diseño o uso"; por lo tanto, la exclusión es condicional: bajo cierta interpretación, una regla cuyo umbral se derivó estadísticamente podría entrar en la definición.

Se prevé que la guía sea más relevante para organizaciones bancarias con activos totales superiores a 30,000 millones de dólares, y deja fuera de su alcance a los modelos de IA generativa y de agentes. Ninguno de estos puntos elimina la expectativa del manual de inspección de que el sistema de monitoreo sea validado de forma independiente. El funcionamiento detallado de la validación se cubre en la guía sobre validación de modelos de AML según las directrices de abril de 2026.

Mantener a los inspectores informados durante el cambio

Los inspectores evalúan el cambio de un sistema de AML basándose en la evidencia escrita de la institución sobre el origen de las nuevas reglas y por qué el cambio representa una mejora. Un responsable de BSA y cumplimiento en un banco patrocinador, al prepararse para una auditoría de un sistema recién adoptado, anticipaba que los inspectores "querrán saber de dónde vienen las reglas... ¿En qué se basaron para los ajustes?".

Un oficial de BSA en una empresa de transferencia de dinero describió la segunda parte como demostrar "a nuestros inspectores y bancos socios que es un cambio para mejor". Un vicepresidente de operaciones de crédito y cumplimiento en una fintech de préstamos con bancos asociados fue más directo: "Tienes que demostrar que lo hiciste. No basta con hacer lo correcto".

Un director de inteligencia financiera en un banco regional describió cómo la familiaridad puede restar flexibilidad: los inspectores se sentían cómodos con el proveedor actual "porque muchas de las entidades que examinan lo usan... Pero, al mismo tiempo, no es personalizable en absoluto". El sistema que mejor conocen los inspectores puede ser el que la institución no puede ajustar a su propio nivel de riesgo.

El manual del FFIEC indica a los inspectores que se "enfoquen en si el banco tiene un proceso eficaz de toma de decisiones sobre SAR, no en las decisiones individuales de SAR", y señala que los bancos "deben documentar las decisiones de SAR, incluyendo la razón específica para presentar o no un informe". Una transición debe mantener ese registro de decisiones continuo en ambos sistemas.

Planifique la comunicación con los inspectores de manera proactiva. Infórmeles sobre el plan y el diseño de la ejecución en paralelo antes de la transición, comparta los resultados y la validación independiente antes de retirar el sistema antiguo, y guarde un registro escrito de cada sesión informativa. Que se requiera una notificación formal dependerá del regulador, de cualquier acuerdo de supervisión y, en el caso de una fintech, del acuerdo con el banco patrocinador; confírmelo con su equipo legal antes de finalizar el plan.

La transición definitiva y cómo se ve el proyecto completado

Una transición limpia permite que cada alerta y caso abierto finalice en el sistema que lo generó y que cada nueva alerta comience en el nuevo sistema. La parte compleja es la actividad que abarca la fecha de corte, ya que un escenario que acumula actividad durante un período retrospectivo necesita el historial anterior al corte para evaluar la actividad posterior. Planifique estas acumulaciones explícitamente y evite que los investigadores trabajen en dos sistemas más tiempo del necesario para resolver los casos abiertos restantes.

La configuración antigua es el resultado del esfuerzo de alguien, así que considérela como conocimiento valioso que debe transferirse. Un oficial de BSA en un banco comunitario comentó sobre el sistema que implementaron: "Siento que es como mi hijo. Si alguien habla mal de él, me duele, porque dediqué mucho tiempo a ajustar las configuraciones". Quienes lo configuraron saben por qué existe cada umbral, y esa es la documentación que solicitará un inspector.

Evalúe tanto al equipo de implementación como al de ventas. Un responsable de tecnología en una empresa de nóminas con servicios bancarios mencionó que una vez elegido el proveedor, "pasamos a su equipo de implementación, que en el pasado a veces nos ha quedado mal". Un vicepresidente de cumplimiento en una empresa de criptopagos, que reabrió su búsqueda tras una transición previa, calificó "la falta de transparencia y comunicación" como el límite definitivo. Pregunte a las referencias cómo se comportó el proveedor después de la firma del contrato.

Después de la puesta en marcha, siga monitoreando el nuevo sistema para detectar desviaciones en sus datos, funciones y resultados, y retire el antiguo solo cuando se cumplan las necesidades de análisis retrospectivo y retención de registros.

Errores comunes en una transición

• Tratar la ejecución en paralelo como si fuera la validación.

• Evaluar el nuevo sistema según qué tan parecido es su volumen de alertas al del sistema anterior.

• Asumir que el historial de SAR, casos y calificaciones de riesgo se migrará de manera idéntica.

• Depender de la validación del proveedor en lugar de encargar una independiente.

• Permitir que los inspectores conozcan el nuevo sistema por primera vez durante la siguiente auditoría.

• Tomar la decisión basándose en el equipo de ventas y conocer al equipo de implementación después de firmar.

• Involucrar a las áreas de riesgo de modelos, seguridad de la información o al banco patrocinador al final del proceso.

¿Se puede modernizar sin reemplazar todo a la vez?

Una transición no tiene por qué reemplazar todo al mismo tiempo. La primera decisión es si mantener el sistema actual, integrar una capa superior o reemplazarlo por completo. Un gerente de TI para sistemas de delitos financieros en una gestora de activos planteó los caminos posibles: "quedarnos donde estamos y no hacer nada; quedarnos donde estamos e integrar algo por encima; o buscar otra solución que reemplace nuestro sistema de flujo de trabajo y de alertas".

Un enfoque por etapas distribuye el cambio en el tiempo, lo cual resulta muy atractivo. Un director de cumplimiento de AML en un operador de juegos en línea prefería "dar pequeños pasos" en lugar de enfrentarse a "una transición total y capacitación inmediata". Un socio en una consultora regulatoria que asesora a bancos aportó su visión sobre AML: los reguladores "no suelen sentirse cómodos con sistemas de monitoreo de transacciones completamente nuevos", pero se les puede guiar "haciendo que el sistema funcione en paralelo por encima y luego usando su sistema gradualmente para asumir funciones".

La forma en que un banco puede realizar esa modernización por etapas conservando sus sistemas preexistentes se explica en la página de Oscilar sobre cómo modernizar el monitoreo sin reemplazar todos los sistemas de origen. Una estrategia por etapas cambia un aspecto de esta guía: cada fase que migre una función al nuevo sistema requerirá sus propias pruebas, validación e informes a los inspectores.

Cómo aborda Oscilar una transición

El enfoque de Oscilar se basa en las mismas cinco decisiones, y cada pregunta de esta guía se aplica a Oscilar tanto como a cualquier otro proveedor. Antes de un compromiso formal, Oscilar estructura la evaluación previa a la producción como una colaboración de diseño: configuración de datos, una prueba retrospectiva contra las alertas históricas de la institución, un modo de simulación en paralelo con el proceso existente y una revisión con participación humana. Sin importar qué proveedor evalúe, defina los criterios de aceptación para una prueba de concepto antes de que comience.

Los agentes pueden funcionar como una capa independiente sobre la infraestructura que ya tiene, o como parte de la plataforma unificada. Oscilar admite pruebas retrospectivas, pruebas A/B y pruebas unitarias para flujos de trabajo de riesgo, mantiene una pista de auditoría completa por decisión con razonamientos almacenados y está diseñado con supervisión humana. Tras la puesta en marcha, Oscilar monitorea las desviaciones de datos, características y conceptos junto con los indicadores clave de rendimiento (KPI) de resultados por segmento. La institución sigue siendo la dueña de sus estándares de validación, autoridad de aprobación y responsabilidad regulatoria.

Haga a Oscilar las mismas preguntas sobre el historial que a cualquier otro proveedor, empezando por qué se migra y en qué formato.

Chartis Research incluyó a Oscilar en la lista FCC50 de 2026, con premios en las categorías de Innovación en IA de Agentes y Personalización Low-Code/No-Code.

Preguntas frecuentes

¿Qué debe saber una institución financiera antes de comprar un software de AML?

Una institución financiera debe saber que la mayor parte del riesgo al comprar un software de AML radica en el cambio del sistema antiguo al nuevo. Antes de firmar, defina las pruebas regulatorias que el proveedor puede ofrecer, qué historial se migra y cómo se concilia, cómo funcionarán ambos sistemas en paralelo y cuándo termina esa fase, quién validará el nuevo sistema y cómo se mantendrá informados a los inspectores.

¿Cuánto tiempo deben funcionar en paralelo el sistema antiguo y el nuevo de AML?

Los sistemas antiguo y nuevo de AML deben funcionar en paralelo hasta que se cumplan los criterios de salida acordados antes de la ejecución. De esta forma, la duración se define mediante evidencias en lugar de un período de tiempo fijo. Los criterios especifican qué diferencias deben explicarse, qué se acepta como explicación y quién aprueba los resultados.

¿Qué sucede con las alertas, casos y SAR históricos al cambiar de sistema de AML?

Las alertas, casos y SAR históricos se migran al nuevo sistema o permanecen legibles en el antiguo, que seguirá funcionando para cumplir con la retención de registros. Las alertas y casos abiertos pueden concluir en el sistema que los generó, mientras que las nuevas alertas comenzarán en el nuevo sistema. Pregunte a cada proveedor qué se migra, en qué formato y cómo se concilia, y asuma que nada se transfiere de manera idéntica.

¿Cuándo se debe informar a los inspectores sobre un cambio de sistema de AML?

Se debe informar a los inspectores sobre un cambio de sistema de AML antes de realizar la transición. Explíqueles el plan, comparta los resultados de la ejecución en paralelo y la validación independiente antes de retirar el sistema antiguo, y lleve un registro de cada sesión informativa. Que se requiera una notificación formal dependerá del regulador, de cualquier acuerdo de supervisión y, para las fintech, del banco patrocinador; confírmelo con anticipación.

¿Qué debe preguntar a las referencias de un proveedor antes de realizar el cambio?

Pregunte a las referencias del proveedor si han pasado por una auditoría con el sistema en funcionamiento y si terceros independientes lo han validado. Dirija las demás preguntas al proceso de implementación más que al de ventas: quién gestionó la transición, cómo se resolvieron los problemas y qué tan abierta fue la comunicación del proveedor después de firmar.

Las cinco decisiones de esta guía son las mismas independientemente del proveedor que elija, y los documentos que generen serán los que revisen los inspectores después de la transición. Para conocer el aspecto de investigación de un cambio, lea sobre la gestión de casos en Oscilar.