Trabajar en BMO, uno de los Big Five bancos de Canadá, mientras soy alguien que sigue de cerca el espacio de desarrollo de IA me ha puesto en una posición interesante. Me importa profundamente usar herramientas modernas para construir mejor software más rápido. Y la banca es un entorno donde se espera que cada herramienta, cada flujo de datos y cada servicio externo pase por capas de revisión de seguridad, validación de compliance y evaluación de riesgo antes de tocar producción.
Estas dos realidades no son incompatibles, pero reconciliarlas exige una mirada clara de dónde están las líneas y por qué. Lo que sigue no es una defensa de la cautela enterprise ni una queja sobre ella. Es lo que encontré útil dentro de las restricciones.
La restricción fundamental: Confidencialidad de datos
Lo más importante de entender sobre usar IA en banca es que la restricción no se trata de ser anti-tecnología. Se trata de datos. Los bancos manejan algunos de los datos personales y financieros más sensibles que existen: números de cuenta, historiales de transacciones, perfiles crediticios, finanzas empresariales, información personalmente identificable de millones de clientes. Los marcos que gobiernan esos datos en Canadá, entre ellos PIPEDA y las directrices de OSFI, no son opcionales y no son abstractos.
Cuando pegas código en una herramienta comercial de chat con IA, ese código potencialmente contiene contexto: nombres de variables, endpoints de API, nombres de columnas de base de datos, lógica de negocio que insinúa estructuras de producto. Incluso si no estás pegando datos reales de clientes, podrías estar revelando arquitectura de sistema confidencial. Esta es una preocupación real, y lo digo como alguien que quiere usar estas herramientas tanto como sea posible.
Lo que no puedes compartir con herramientas de IA
Esta es mi lista práctica de lo que absolutamente no entra en ninguna herramienta de IA externa en un contexto bancario:
- Cualquier dato real de cliente, incluso muestras 'anonimizadas': el riesgo de re-identificación es real
- URLs o schemas de endpoints de API internos que no están documentados públicamente
- Nombres de tablas y columnas de base de datos de sistemas de producción
- Flujos de autenticación, estructuras de tokens, o lógica de middleware de seguridad
- Lógica de negocio que revela funcionalidades de producto no lanzadas o estrategias de precios
- Workflows de compliance, implementaciones de audit trail, o código de reportes regulatorios
- Cualquier cosa marcada como confidencial, propietaria o interna en el sistema de clasificación de tu organización
- Código de repositorios con acceso restringido
Esta no es una lista legal completa, eso es trabajo del equipo de seguridad de tu organización. Esta es mi heurística operativa personal. Cuando tengo dudas, elimino el contexto agresivamente antes de hacer el prompt.
Lo que sí puedes hacer con IA en banca
La lista anterior suena limitante. La mayoría de los problemas difíciles en desarrollo enterprise con Angular no son específicos de la banca. Son problemas de escala, patrones, testing y arquitectura. Y la IA es extremadamente útil para todos ellos.
- Generar boilerplate para componentes, servicios y tests usando schemas genéricos o anonimizados
- Explicar conceptos, patrones y APIs de Angular con los que estás menos familiarizado
- Depurar errores de compilación de TypeScript pegando mensajes de error sanitizados
- Refactorizar lógica usando estructuras de datos abstractas (reemplazando nombres de campos reales con genéricos)
- Escribir funciones utilitarias: formateadores de fechas, validadores, transformadores de strings. No contienen datos sensibles
- Revisar accesibilidad: patrones ARIA, navegación por teclado, gestión de foco
- Redactar documentación, comentarios o descripciones de PR a partir de código sanitizado
- Aprender sobre operadores RxJS, patrones de signals, o internals de Angular
La habilidad clave es la abstracción. Me he vuelto bueno traduciendo un problema real a una versión estructuralmente equivalente pero neutral en datos del mismo problema. Los detalles específicos de banca viven en mi cabeza y en nuestros sistemas internos. La IA me ayuda a resolver el desafío estructural.
Un ejemplo concreto de abstracción segura
Así se ve la abstracción. El sistema de abajo está inventado para este post, porque el real no es mío para publicarlo, pero la forma del error es idéntica. Digamos que un componente consulta un endpoint cada cierto tiempo y muestra un número de la respuesta, y quiero ayuda con el patrón de reactividad. Esta es la versión que nunca enviaría:
// DON'T DO THIS
Here is our FleetStatusComponent that pulls from the /api/v2/fleet/summary endpoint.
It reads from fleetState.activeVehicles and needs to refresh every 30s...
[actual internal code pasted here]En cambio, lo abstraigo completamente:
// DO THIS INSTEAD
I have an Angular component that polls a REST endpoint every 30 seconds and displays
a numeric value from the response. Using signals, I need to handle:
1. A loading state on initial fetch
2. A silent background refresh (no loading spinner on re-poll)
3. An error state that doesn't clear the last known good value
The endpoint returns { value: number; lastUpdated: string }.
What's a clean signal-based pattern for this?El segundo prompt me da todo lo que necesito para resolver el problema real y no revela nada del sistema del que salió. El desafío técnico es idéntico. Los datos son genéricos. Ese paso de traducción es toda la habilidad.
Procesos de aprobación enterprise para herramientas de IA
Más allá de las preocupaciones de datos, el uso enterprise de IA pasa por revisión de adquisiciones y seguridad. Si tu organización está evaluando una herramienta de IA, un plugin de asistente de código para IDE, una suscripción enterprise de LLM, una licencia de GitHub Copilot Business, espera que este proceso tome meses, no días. Involucra evaluaciones de seguridad del proveedor, acuerdos de procesamiento de datos, revisión de dónde se almacenan tus datos y si se usan para entrenamiento, y aprobación de múltiples stakeholders.
Esto es frustrante desde el punto de vista de productividad. Para cuando una herramienta pasa la revisión, la versión que evaluaste puede estar desactualizada. También he llegado a respetar por qué existe este proceso. Una brecha de datos involucrando la cadena de herramientas de desarrollo de un banco no es un escenario hipotético, ha ocurrido en instituciones financieras globalmente. La cautela está calibrada al riesgo real.
Mi consejo para navegar esto: presiona temprano y proporciona evidencia. Si quieres que se apruebe una herramienta, construye un caso de negocio que incluya documentación de seguridad, casos de uso específicos, e instituciones comparables que ya la hayan adoptado. Los champions internos que pueden articular los controles de riesgo junto con el beneficio de productividad avanzan más rápido que el puro entusiasmo.
Herramientas internas de IA: El mejor camino
La verdadera respuesta no es una forma más segura de usar una herramienta comercial externa. Es un modelo que corre donde los datos ya viven. La versión gratuita está más cerca de lo que la mayoría supone. Modelos de pesos abiertos servidos localmente con Ollama o llama.cpp no cuestan nada más allá del hardware que ya tienes, no hacen ninguna llamada de red, y son suficientemente buenos para el boilerplate, las explicaciones y la escritura de tests, que de todas formas son la mayor parte del uso diario. Puedes probar la idea en una laptop antes de que alguien firme un contrato, y una demo local funcionando es un argumento mucho mejor en una conversación de adquisiciones que una diapositiva.
La versión de pago es la misma idea con las GPUs de otro y un acuerdo firmado: un despliegue gestionado dentro de tu propia tenancy cloud, donde los prompts y outputs se quedan dentro del perímetro de la organización. En cualquiera de los dos casos el tradeoff es el mismo. Estos modelos son más débiles que los de frontera que usas personalmente, y les puedes dar contexto completo. Un modelo más débil con el problema real delante le gana a un modelo más fuerte para el que tuviste que abstraer todo.
Si puedes influir en la decisión, aboga por el despliegue que controlas en lugar de la suscripción que no controlas. La brecha de capacidad se reduce cada pocos meses. La brecha de compliance no.
Cómo luce la productividad en la práctica
Dadas todas las restricciones, ¿cómo luce mi flujo de trabajo real aumentado con IA en el trabajo? En BMO, el equipo usa un asistente aprobado, GitHub Copilot Business, que yo configuré con guardrails. Dentro de ese setup, uso IA aproximadamente para estas cosas, aproximadamente en este orden de frecuencia:
- 1. Generar boilerplate de componentes y servicios a partir de specs sanitizadas: ahí es donde el ahorro de tiempo es más evidente
- 2. Escribir casos de test a partir de comportamiento descrito: el patrón de prompt basado en escenarios que uso me da la mayoría de los casos de test útiles sin código sensible
- 3. Explicar APIs desconocidas o internals de Angular que encuentro en código existente
- 4. Redactar descripciones de PR a partir de diffs sanitizados
- 5. Refactorizar versiones abstractas de problemas de rendimiento y luego aplicar el patrón manualmente al código real
No uso IA para: nada que toque autenticación, nada que requiera compartir schemas internos, ninguna tarea donde el contexto en sí sea sensible. Para eso, trabajo de la manera tradicional, que sigue siendo perfectamente rápida cuando tienes más de una década de experiencia.
Hay una tensión obvia en todo esto y es lo primero que un lector atento debería preguntar. Si nada interno va a una herramienta de IA, ¿qué hace un asistente de IDE con el repositorio abierto delante? No son el mismo canal. Copilot Business lee el workspace abierto bajo contrato: los prompts y las sugerencias no se retienen y no se usan para entrenar modelos, y los administradores pueden excluir rutas para que el asistente nunca las vea. Ese es un canal revisado y con rastro documental. Una ventana de chat de consumo no lo es. La disciplina de abstracción de este post es sobre el segundo canal y sobre todo lo que el contrato no cubre. El primero se gobierna con la lista de exclusión de contenido y con los repositorios en los que la licencia está activada, y si no sabes qué hay en esa lista de exclusión para tu propio repo, eso es lo que tienes que ir a averiguar hoy.
El lado cultural: Actitudes de los compañeros
Algo que no esperaba es lo lejos que están entre sí las actitudes hacia las herramientas de IA dentro de una organización grande. El escepticismo es común, a veces sobre la calidad del output y a veces sobre el riesgo de datos, y ambas versiones son posiciones razonables sostenidas por buenos desarrolladores. Lo que más me sorprendió es cuánta gente lo trata como binario: o la herramienta está aprobada para todo o está prohibida por completo. No es ninguna de las dos. La conversación útil solo empieza cuando esa suposición desaparece.
Intento sostener una posición específica: entusiasmado con la productividad, riguroso con las restricciones, y vocal a favor de mejores herramientas internas. No soy la persona que les dice a los colegas qué no pueden usar. Soy la persona que dice así es como se usa esto para que no se convierta en tu problema dentro de seis meses.
Lo que le diría a mi yo del pasado
Si pudiera dar un consejo a alguien que se une a una gran institución financiera con una mentalidad orientada a IA: no llegues esperando conectar tu flujo de trabajo personal directamente. Las herramientas que amas fuera del trabajo pueden no estar aprobadas. Los datos que normalmente darías como contexto están fuera de límites. Eso es real, y adaptarse toma tiempo.
Pero las habilidades subyacentes de prompt engineering, saber qué preguntar y cómo estructurar la pregunta, son completamente transferibles. Solo las rediriges. En lugar de hacer prompts con contexto completo, aprendes a hacer prompts con abstracciones precisas. En lugar de obtener una solución completa, obtienes un patrón estructural que aplicas con tu conocimiento interno. Es un ritmo diferente pero no uno menos productivo, una vez que te adaptas.
La restricción no es enemiga de la productividad. La restricción es el parámetro alrededor del cual diseñas. Los ingenieros hacen eso todos los días.
Referencias
- Ollama, para correr modelos de pesos abiertos localmente. https://ollama.com
- Azure OpenAI Service. https://azure.microsoft.com/en-us/products/ai-services/openai-service
- AWS Bedrock. https://aws.amazon.com/bedrock/
- PIPEDA. https://www.priv.gc.ca/en/privacy-topics/privacy-laws-in-canada/the-personal-information-protection-and-electronic-documents-act-pipeda/