TECOLOGY / IA LOCAL PARA BANCA / OCTUBRE 2026
Guía para evaluar un piloto de IA local en banca
Una ruta de trabajo para acordar alcance, responsabilidades y evidencias antes de ampliar el uso.
Documento orientativo. Funciones, entregables y condiciones se acuerdan para cada proyecto.
1. Delimitar el objetivo
Elegir una tarea interna y describir quién utiliza el resultado y quién lo valida. Un punto de partida es la consulta de procedimientos aprobados. Especificar exclusiones: transacciones, decisiones crediticias, integración al core y acceso a información real no aprobada quedan fuera del piloto salvo un alcance específico posterior.
2. Asignar responsables
Operaciones define la tarea y las respuestas de referencia; tecnología evalúa capacidad e integración; seguridad revisa accesos y flujos de datos; riesgo y cumplimiento determinan las revisiones internas pertinentes. Acordar quién aprueba fuentes, cambios, pruebas y la decisión de continuidad.
3. Preparar fuentes y entorno
Inventariar documentos, clasificación, propietarios, versiones y derechos de uso. Preferir un conjunto aprobado sin datos de clientes, o muestras sintéticas o anonimizadas revisadas por la entidad. Definir entorno separado, usuarios de prueba, conectividad, almacenamiento, registros y respaldo.
4. Acordar criterios antes de probar
| Dimensión | Evidencia a preparar |
|---|---|
| Respuesta y referencias | Comparación con fuentes vigentes y evaluación por el responsable del proceso. |
| Permisos | Pruebas por rol, fuentes restringidas y consultas fuera de alcance. |
| Resistencia a instrucciones en documentos | Casos de prueba para comprobar que contenido documental no modifica permisos ni reglas de la aplicación. |
| Capacidad | Tiempos de respuesta y recursos bajo carga representativa. |
| Continuidad | Prueba de respaldo y recuperación acordada. |
| Costo | Comparación de alternativas para la misma carga y horizonte. |
Los umbrales de aceptación los acuerda el equipo del proyecto; esta guía no fija métricas universales.
5. Registrar resultados y limitaciones
Documentar modelos, versiones, configuración y fuentes utilizadas. Registrar errores, referencias incorrectas, consultas sin respaldo y fallos de acceso. Acordar protección y retención de evidencias. Ninguna muestra de prueba permite prometer ausencia total de errores o incidentes.
6. Definir entregables
El acuerdo puede incluir arquitectura, inventario de componentes y licencias, matriz de accesos, entorno de evaluación, guía de operación, registro de pruebas, formación y recomendaciones. Confirmar por escrito qué entrega Tecology, qué aporta la entidad y qué queda excluido, junto con soporte, garantía y plazos.
7. Decidir si continuar
Revisar evidencia con los responsables: ajustar, ampliar o detener. Antes de operar con mayor alcance, definir administración, mantenimiento, actualizaciones, respuesta ante incidentes y revisión periódica de fuentes. Las integraciones posteriores deben tener evaluación y aceptación propias.
Preparar la reunión
Resume el proceso, fuentes disponibles, usuarios simultáneos esperados, infraestructura existente y restricciones de integración. No adjuntes documentos restringidos al contacto inicial. Escribe a IA@tecology.com.pa. Esta guía es de planificación de un proyecto tecnológico; no acredita cumplimiento regulatorio.