Inteligencia Artificial en GST, explicada para todos
Esta guía reúne, en un solo lugar y en lenguaje claro, cómo GST adopta y gobierna la Inteligencia Artificial: qué herramientas usamos, quién puede usarlas, qué está permitido y qué no, y cómo cuidamos los datos y el cumplimiento normativo.
En GST queremos que uses la IA para trabajar mejor y más rápido, utilizando las herramientas aprobadas, buscando proteger los datos sensibles y revisando siempre lo que la IA produce. Esta página te explica las reglas y te ayuda a resolver dudas mientras leés.
Guía Cómo usar esta página
Elegí el tipo de lectura
Arriba a la derecha, Simple muestra resúmenes y lo imprescindible; Completo agrega tablas, matrices RACI, KPIs y configuraciones técnicas. Podés cambiar cuando quieras.
Navegá por el menú lateral
A la izquierda tenés el índice completo, agrupado en (A) el Modelo de Gobierno y (B) la Política. La sección que estás leyendo se resalta sola.
Buscá tus dudas
El buscador resalta resultados en vivo. Si tenés una pregunta puntual, mirá primero Preguntas frecuentes.
Apoyate en los recuadros
Mirá los colores: amarillo = atención, rojo = prohibido, verde = permitido. Los recuadros 💡 traducen lo técnico a lenguaje simple.
Panorama General: Los dos documentos de un vistazo
El gobierno de IA en GST se apoya en dos documentos complementarios. Uno dice “qué reglas seguimos” (la Política) y el otro “cómo lo implementamos con herramientas y estructura” (el Modelo de Gobierno).
Modelo de Gobierno de IA
Documento corporativo unificado. Define la arquitectura de herramientas, la estructura de gobierno, los criterios de acceso, la seguridad, el control del gasto y las métricas. Tiene dos partes: Áreas de Negocio y Desarrollo de Software.
Política de Uso Responsable de la IA
Política corporativa formal (GST-23-010). Establece los principios éticos, los usos permitidos y prohibidos, la homologación de herramientas, la protección y clasificación de datos, y el régimen de sanciones. Aplica a todo el Grupo.
La Política (B) marca los límites y principios obligatorios para todos. El Modelo de Gobierno (A) los lleva a la práctica con herramientas concretas (Microsoft 365 Copilot, agentes de IA, GitHub Copilot, Claude Code), estructura de comité y métricas. Si tenés una duda de “¿qué puedo hacer?”, mirá la Política; si es “¿con qué herramienta y cómo me habilitan?”, mirá el Modelo.
Documento A · Marco general Modelo de Gobierno de IA
Un único marco para toda la organización, con principios y estructura comunes, dividido en dos partes según el tipo de trabajo: las áreas de negocio y los equipos de desarrollo de software.
GST adopta la IA de forma ordenada y segura. Para eso fija reglas iguales para todos (principios, identidad única, no usar tus datos para entrenar modelos, supervisión humana, control del gasto) y luego adapta las herramientas a cada tipo de tarea.
Alcance: ¿a quién aplica?
Aplica a todo el grupo GST y a todas las personas que usan asistentes y herramientas de IA generativa provistas y aprobadas por la organización, en cualquiera de sus dos dominios:
Áreas de Negocio y soporte
Operaciones, Finanzas, Capital Humano, Comercial, Atención al Cliente, Legales y demás funciones administrativas. La IA como asistente personal de productividad y chat de consultas (Parte I).
Desarrollo de Software
Desarrolladores, QA con coding, ingenieros de plataforma y de datos. La IA como asistente de codificación y herramienta de modernización de software (Parte II).
Toda adquisición o uso de IA fuera del catálogo corporativo aprobado se considera Shadow AI / Shadow IT y está expresamente prohibida. El desarrollo ciudadano se encauza por el carril de graduación.
Los 3 objetivos principales
Productividad medible
Ganar horas, calidad y velocidad de entrega, habilitando a cada persona con la herramienta adecuada a su función.
Seguridad y cumplimiento
Operar como una entidad regulada: proteger la información sensible de clientes, terceros y de la organización.
Gasto bajo control (FinOps)
Evitar la proliferación de licencias y el consumo no gestionado; asignar recursos donde el caso de uso justifica el retorno.
Principios comunes
| Principio | Qué significa |
|---|---|
| Mínima fricción | Las herramientas se integran de forma nativa con Microsoft Entra ID y el ecosistema Microsoft 365/Azure ya instalado. |
| Arquitectura de dos capas | Una Capa Estándar de cobertura amplia y mínima fricción, y una Capa Especializada focalizada en casos de alto valor. Son complementarias, no excluyentes. |
| Identidad federada | Single Sign-On vía Entra ID, con MFA obligatorio y alta/baja automatizada (SAML/SCIM). |
| No-entrenamiento y no-retención | Garantía contractual de que el contenido corporativo no entrena modelos, con Zero Data Retention donde el proveedor lo ofrezca — obligatorio para GST. |
| Grounding y permisos | Las respuestas se anclan en información corporativa verificable y nunca exponen contenido fuera del acceso legítimo del usuario. |
| Supervisión humana | Toda salida destinada a clientes, reguladores, decisiones o sistemas productivos debe ser revisada y validada por la persona responsable. |
| Gestión financiera activa | Presupuestos cerrados, visibilidad del consumo, hard-caps técnicos, alertas escalonadas y asignación por valor. |
| Catálogo único | La IA se adquiere y usa exclusivamente por el catálogo aprobado; el Shadow AI está prohibido y el desarrollo ciudadano se encauza por el carril de graduación. |
| Cumplimiento regulatorio | Anclado en el marco aplicable a GST (ej.: SSN, BCRA, Ley 25.326 y Ley 27.401). |
A · Parte I Áreas de Negocio
Microsoft 365 Copilot (Capa Estándar) + Agentes de IA especializados (Capa Especializada).
Si trabajás en un área de gestión de negocio o administrativa (no IT), tu IA principal es Copilot dentro de Office (Outlook, Word, Excel, Teams): te ayuda a redactar, resumir reuniones, armar documentos y analizar planillas. Para consultas profundas sobre normativa, pólizas o procesos, algunas áreas suman agentes especializados que responden con cita a la fuente.
Las dos capas en detalle
Capa Estándar — Microsoft 365 Copilot
Asistente de productividad embebido en Office, anclado a Microsoft Graph respetando los permisos de cada usuario. Casos típicos: correos, resúmenes de reuniones, documentos, presentaciones y análisis de planillas.
Capa Especializada — Agentes de IA
Agentes por dominio anclados a bases de conocimiento curadas (pólizas, condiciones de clientes, información financiera, normativa, procesos), con cita explícita a la fuente para reducir alucinaciones. Construidos sobre Copilot Studio o Claude Enterprise.
📋 Tabla comparativa completa de las dos capas ▸
| Dimensión | Capa Estándar · M365 Copilot | Capa Especializada · Agentes |
|---|---|---|
| Cobertura objetivo | 80% del personal administrativo aprobado | 20% focalizado |
| Perfil de usuario | Operaciones, Finanzas, Legales, RR.HH., Comercial, Atención al Cliente | Analistas y especialistas con consulta sobre conocimiento de dominio |
| Casos de uso | Correos, resúmenes, documentos, presentaciones, análisis de planillas | Consultas sobre productos, normativa, procesos, RR.HH.; análisis documental profundo, agentes específicos |
| Plataforma / modelos | Office + modelos como GPT, Claude vía Copilot | Copilot Studio; Claude y equivalentes |
| Capa de datos | Correo, archivos, Teams, SharePoint respetando permisos | Bases de conocimiento curadas y de alcance acotado |
| Identidad | Entra ID (nativo) | Entra ID vía SAML/SCIM |
| Métrica primaria | Adopción activa y horas ahorradas | Tasa de resolución y calidad de respuesta |
⚙️ Configuración corporativa estándar (seguridad) ▸
Capa Estándar — Microsoft 365 Copilot
- SSO vía Entra ID con MFA obligatorio; alta/baja automatizadas.
- Respeto estricto de permisos: solo expone contenido al que el usuario ya tiene acceso.
- Garantía contractual de no-entrenamiento y no-retención de prompts más allá de la sesión.
- Audit logs de identidad integrados al SIEM corporativo.
Capa Especializada — Agentes de IA
- Plan Enterprise con identidad federada (SAML 2.0 + SCIM).
- No-entrenamiento y Zero Data Retention — obligatorio para GST.
- Bases de conocimiento curadas, versionadas y con control de acceso por rol.
- Respuestas con cita a la fuente; guardarraíles que bloquean temas fuera de alcance.
🏛️ Estructura de gobierno: Comité y matriz RACI ▸
El Comité de Gobernanza de IA es el órgano de decisión estratégica. Cadencia: mensual los primeros 6 meses, luego trimestral. Las decisiones materiales requieren mayoría calificada.
| Rol | Ocupante | Responsabilidad principal |
|---|---|---|
| Owner | Pilar Modernización | Convocatoria, agenda, escalamiento al Comité Ejecutivo |
| CISO | Seguridad de la Información | Controles de seguridad, gestión de incidentes |
| Compliance Officer | Cumplimiento Normativo | Mapeo BCRA / SSN / Ley 25.326 / Ley 27.401 |
| Referentes de Negocio | Líderes de áreas | Casos de uso, priorización, validación de valor |
| FinOps Lead | Finanzas / Estrategia Tecnológica | Presupuesto, monitoreo de consumo, intercompany |
| CoE de IA | A definir | Adopción, capacitación, métricas y soporte |
| Proceso | Comité | CISO | Negocio | FinOps |
|---|---|---|---|---|
| Política de uso aceptable | A | C | C | I |
| Alta/baja de licencias Capa Estándar | I | R | C | C |
| Habilitación Capa Especializada | A | C | R | C |
| Curaduría de bases de conocimiento | I | C | R | I |
| Definición y revisión de hard-caps | A | I | I | R |
| Notificación de ciberincidentes | I | R | I | I |
| Reportería mensual de KPIs | R | R | R | R |
¿Quién accede y cómo?
Capa Estándar (Copilot)
Acceso prácticamente universal para roles administrativos. Requiere: pertenecer a un área de negocio/soporte, completar la capacitación obligatoria, firmar la Política de Uso Aceptable, tener cuenta en Entra ID con MFA, solicitud formal del responsable vía InvGate y aprobación presupuestaria.
Capa Especializada (Agentes)
Universo acotado, asignado por relevancia funcional y valor del caso de uso (puede revisarse cada semestre). Solicitud formal vía InvGate. Perfiles: analistas de Operaciones (pólizas, siniestros, procedimientos, situaciones financieras, clientes), RR.HH., Finanzas, Comercial/Atención al Cliente y referentes de Compliance/Legales.
Inactividad > 30 días dispara revisión automática de la licencia. Cambiar a un rol fuera de las áreas elegibles implica reasignación o retiro. El incumplimiento material de la política suspende el acceso y deriva al Comité.
Seguridad, privacidad y cumplimiento
GST es una entidad regulada. Por eso la IA funciona con controles: respeto de permisos, registros de auditoría de identidad y contratos que garantizan que tus datos no entrenan al modelo.
Marco regulatorio aplicable a GST
| Norma | Alcance relevante para la IA |
|---|---|
| Resolución SSN 38477 | Continuidad operativa y seguridad de la información en aseguradoras. Aplica directamente a GST. |
| BCRA Com. “A” 7724 (10-mar-2023) | Requisitos mínimos de gestión de riesgo de TI y seguridad. Aplica de manera referencial. |
| BCRA Com. “A” 8280 (2025) | Respuesta y recuperación ante ciberincidentes (RRCI), incluida la cadena de proveedores. |
| Ley 25.326 | Protección de Datos Personales; transferencias internacionales con país adecuado o cláusulas tipo. Autoridad: AAIP. |
| Ley 27.401 | Responsabilidad penal de personas jurídicas: la IA debe estar en el mapa de riesgos del Programa de Integridad. |
Controles transversales
- Respeto de permisos: ninguna respuesta expone contenido fuera del acceso del usuario.
- SIEM corporativo: ingestión de audit logs de identidad de ambas capas con alertas.
- Catálogo único: comprar IA fuera del catálogo es Shadow AI, prohibido.
Control del gasto (FinOps) y métricas
Para que el costo no se dispare, hay presupuestos cerrados y topes técnicos (hard-caps) con alertas: al 70% avisa al referente, al 85% al líder, y al 100% se bloquea hasta reaprobar. Se mide adopción, horas ahorradas y calidad.
💰 Hard-caps y alertas escalonadas ▸
| Dimensión | Hard-cap | Alertas |
|---|---|---|
| Licencias Capa Estándar (por usuario) | Padrón aprobado por área | Revisión mensual de inactivas (>30 días) |
| Consumo de agentes por área | Cuota mensual del área | 70% → referente · 85% → líder + CoE · 100% → bloqueo |
| Total mensual organización | 1/12 del presupuesto anual + 15% | Reportes semanales al FinOps Lead |
📈 Cuadro de mando de KPIs (Año 1) ▸
| Indicador | Meta año 1 | Cadencia |
|---|---|---|
| Adopción activa | ≥ 80% de licencias con uso significativo | Mensual |
| Horas ahorradas por usuario | ≥ 3 hs/semana promedio | Trimestral |
| Tasa de resolución (agentes) | ≥ 75% sin escalamiento | Mensual |
| Calidad de respuestas | ≥ 90% sin corrección material | Trimestral |
| Costo por usuario efectivo | Dentro de la banda presupuestada | Mensual |
| ROI año 1 | Positivo (productividad > inversión) | Anual |
| Incidentes de seguridad | Cero materiales | Continuo |
⚠️ Principales riesgos y mitigaciones ▸
| Riesgo | Prob. | Impacto | Mitigación |
|---|---|---|---|
| Fuga de datos sensibles (PII, financieros, RR.HH.) | Media | Crítico | Respeto de permisos; no-entrenamiento y no-retención contractual; capacitación obligatoria |
| Respuestas incorrectas / alucinaciones | Media | Alto | Agentes con cita a la fuente; supervisión humana; muestreo |
| Sobre-confianza del usuario | Media | Alto | Capacitación; etiquetar salidas como asistidas por IA; validación |
| Overrun presupuestario | Media | Alto | Hard-caps; alertas; asignación por valor |
| Shadow AI | Alta | Medio-Alto | Catálogo único; carril de graduación + catálogo de activos por nivel; bloqueo de dominios; auditoría |
Política de uso aceptable · Áreas de Negocio
✓ Usos permitidos
- Redactar, mejorar y resumir correos y documentos.
- Sintetizar reuniones y extraer puntos de acción de transcripciones autorizadas.
- Elaborar informes, minutas y presentaciones con supervisión humana.
- Analizar planillas y datos no clasificados como restringidos.
- Buscar información corporativa a la que ya tenés acceso legítimo.
- Consultar las bases de conocimiento aprobadas (pólizas, normativa, procesos, políticas internas, regulaciones).
✕ Usos prohibidos
- Ingresar datos reales de asegurados o terceros (PII) en herramientas no aprobadas.
- Ingresar credenciales, secretos, tokens o info restringida sin autorización del CISO.
- Comunicar una salida de la IA a clientes o reguladores sin revisión humana.
- Habilitar decisiones automáticas sobre personas sin un “gate” humano.
- Usar herramientas o planes no aprobados (incluye planes gratuitos individuales).
- Eludir etiquetas de sensibilidad, DLP o cuotas presupuestarias.
Aceptar la política y recertificarla cada año · revisar y validar toda salida antes de usarla o comunicarla · reportar de inmediato incidentes o exposiciones de datos · mantenerte actualizado sobre cambios.
A · Parte II Desarrollo de Software
GitHub Copilot Enterprise (Capa Estándar) + Claude Code (Capa Especializada).
Si programás, tu IA de todos los días es GitHub Copilot (autocompletado, tests, revisión inicial de PRs). Para tareas grandes y difíciles — modernizar sistemas viejos, entender monolitos enormes, refactor de muchos archivos — algunos squads suman Claude Code, que maneja muchísimo más contexto.
Las dos capas en detalle
Capa Estándar — GitHub Copilot Enterprise
Asistente de codificación integrado a Azure, GitHub Enterprise e IDEs. Ofrece indemnización por propiedad intelectual, suggestion filtering, content exclusions y modelo multi-proveedor (GPT-5, Claude, Gemini).
Capa Especializada — Claude Code
Para refactor multi-archivo, análisis de monolitos y modernización de legacy. Ventana de contexto extendida (500K–1M tokens) y orquestación de sub-agentes. Anthropic sostiene la certificación ISO 42001.
📋 Tabla comparativa completa de las dos capas ▸
| Dimensión | Capa Estándar · Copilot Enterprise | Capa Especializada · Claude Code |
|---|---|---|
| Cobertura objetivo | 70% del equipo | 30% focalizado |
| Perfil | Desarrolladores generalistas, full-stack, frontend, backend, QA con coding | Senior/staff, arquitectos, modernización legacy, plataforma de datos |
| Casos de uso | Coding general, tests unitarios, PR review, documentación | Refactor multi-archivo, análisis de monolitos, agentes autónomos |
| Modelos | GPT-5, Claude, Gemini (multi-modelo) | Claude Sonnet 4.6, Opus 4.7, Haiku 4.5 |
| Ventana de contexto | 64K–200K tokens | 500K (Enterprise) – 1M (Claude Code) |
| IDE | VS Code, Visual Studio | VS Code, CLI |
| Métrica primaria | Tasa de aceptación inline (≥30%) | Lead time DORA, calidad de refactor |
⚙️ Configuración corporativa estándar (seguridad) ▸
Capa Estándar — Copilot Enterprise
- Activación obligatoria de suggestion filtering (bloqueo de coincidencias con código público).
- Content exclusions sobre repos con lógica actuarial, motores anti-fraude o integraciones con la SSN.
- No almacenamiento local de prompts y suggestions más allá de lo necesario para la sesión activa.
- Política de selección de modelos: Sonnet/GPT-5 por defecto; premium solo justificado.
Capa Especializada — Claude Code
- Plan Enterprise (mínimo 50 asientos contractuales). Zero Data Retention (0 días) obligatorio para GST.
- SSO SAML 2.0 + SCIM; audit logs de identidad integrados al SIEM.
- Default Sonnet 4.6; Opus 4.7 bajo aprobación del líder técnico y dentro del pool de tokens.
- Skills/Knowledge Bases corporativos: guías de arquitectura, estándares, glosario de dominio.
🏛️ Comité y matriz RACI (Desarrollo) ▸
Misma estructura de Comité que en Áreas de Negocio, sumando al Arquitecto Empresarial (estándares técnicos, política de modelos, content exclusions).
| Proceso | Comité | CISO | Arq. | FinOps |
|---|---|---|---|---|
| Política de uso | A | A | R | I |
| Alta/baja de seats Capa Estándar | I | R | C | C |
| Asignación seat Capa Especializada | I | R | I | I |
| Content exclusions sobre repos | I | A | C | I |
| Selección de modelo (Opus/GPT-5 Pro) | A | C | C | C |
| Definición de hard-caps | A | I | I | R |
| Notificación de ciberincidentes | I | R | I | I |
| Reportería mensual de KPIs | R | R | R | R |
¿Quién accede y cómo?
Capa Estándar (Copilot)
Universal entre quienes escriben código. Requiere pertenecer a equipos de Tecnología con responsabilidades de desarrollo o usuarios expresamente autorizados, capacitación obligatoria, firma de la política, Entra ID + MFA y solicitud formal del Director de Área.
Capa Especializada (Claude Code)
Por seniority y pertinencia técnica (revisable cada semestre): senior/staff engineers, squads críticos (modernización de core, plataforma de datos, anti-fraude, integraciones con reguladores) y plataforma DevOps/reliability engineering.
Seguridad, privacidad y cumplimiento
Mismo marco regulatorio que las Áreas de Negocio (SSN 38477, BCRA “A” 7724 y 8280, Ley 25.326, Ley 27.401). Controles propios de desarrollo:
- SIEM corporativo: ingestión de audit logs de identidad de ambas capas con alertas SOC.
- Catálogo único: IA de desarrollo fuera del catálogo es Shadow IT, prohibido.
Garantías contractuales de no-entrenamiento
| Herramienta | Garantía |
|---|---|
| GitHub Copilot Enterprise | No usa código, prompts ni suggestions de planes Business/Enterprise para entrenar. Indemnización por PI incluida. Suggestion filtering activado. |
| Claude Enterprise / Claude Code | Anthropic garantiza por contrato que inputs/outputs no entrenan modelos. Zero Data Retention (0 días) — obligatorio para GST. |
Gasto (FinOps), KPIs y riesgos
Los modelos premium (Opus 4.7, GPT-5 Pro) cuestan más, así que solo se usan cuando el caso lo justifica (refactor crítico, debugging profundo). Para lo trivial se prefieren modelos económicos (Haiku). Hay topes por seat y por squad, con alertas al 70/85/100%.
💰 Hard-caps y política de selección de modelos ▸
| Dimensión | Hard-cap | Alertas |
|---|---|---|
| Premium requests Copilot por seat | Pool incluido + 20% | 70% usuario · 85% líder · 100% bloqueo |
| Tokens Claude por squad | Cuota mensual del squad | 70% Champion · 85% líder + CoE · 100% bloqueo |
| Total mensual organización | 1/12 anual + 15% | Reportes semanales al FinOps Lead |
- Default Capa Estándar: mejor relación calidad/costo (Sonnet o GPT-5 estándar).
- Default Capa Especializada: Claude Sonnet 4.6.
- Premium (Opus 4.7, GPT-5 Pro): solo tareas justificadas, con autorización del líder técnico.
- Económicos (Haiku 4.5): tareas triviales, ediciones simples, boilerplate.
📈 KPIs de Año 1 (Desarrollo) ▸
| Indicador | Meta año 1 | Fuente |
|---|---|---|
| Adopción activa | ≥ 80% de seats con uso significativo | Dashboards Copilot/Claude |
| Acceptance rate inline | ≥ 30% organizacional | Dashboards Copilot |
| Lead time DORA | Reducción ≥ 25% vs. baseline | Pipeline DevOps + Jira |
| Defect escape rate | Sin deterioro (≤ baseline + 5%) | Bug tracking + SIT/UAT |
| Cobertura de tests | + ≥ 10 puntos porcentuales | SonarQube |
| Incidentes de seguridad | Cero materiales | CISO / SIEM |
⚠️ Riesgos y mitigaciones (Desarrollo) ▸
| Riesgo | Prob. | Impacto | Mitigación |
|---|---|---|---|
| Fuga de datos (PII, secrets, lógica de negocio) | Media | Crítico | Content exclusions; pre-commit hooks; Zero Data Retention contractual; capacitación obligatoria |
| Calidad inconsistente / defectos en producción | Media | Alto | Code review obligatorio; quality gates SAST/DAST; pin de modelo en CI |
| Overrun presupuestario | Alta | Alto | Hard-caps por seat/squad; alertas; política de modelos |
| Lock-in técnico | Alta | Medio-Alto | Arquitectura multi-modelo; estándar MCP |
| Shadow IT | Media | Medio-Alto | Catálogo único; carril de graduación bajo SDLC de GST; NHI; bloqueo de dominios; auditoría |
Política de uso aceptable · Desarrollo
✓ Usos permitidos
- Autocompletado y sugerencias inline al codificar.
- Generar pruebas unitarias y de integración.
- Generar código bajo estándares GST y supervisión humana.
- Generar y revisar documentación técnica.
- Refactor asistido y modernización de frameworks.
- Explicar código existente y analizar monolitos legacy.
- Revisión inicial de PRs (no sustituye la revisión humana).
- Generar boilerplate, esqueletos de servicios e IaC.
✕ Usos prohibidos
- Ingresar datos reales de asegurados o terceros (PII).
- Ingresar credenciales de producción, secretos, llaves API o certificados.
- Procesar info confidencial/restringida sin autorización del Director del área y el CISO.
- Mergear código generado por IA sin code review humano.
- Ejecutar cambios autónomos en producción sin “gate” humano.
- Usar herramientas o tiers no aprobados (incluye planes gratuitos).
- Eludir content exclusions o cuotas presupuestarias.
A · Transversal Gobernanza de Shadow AI y Desarrollo Ciudadano
Cómo GST encauza el uso de IA y el software creado fuera de TI sin frenar la innovación.
En GST no está autorizada la creación de software por fuera del área de desarrollo de IT. Pero se entiende que el uso de IA puede generar nuevos espacios y oportunidades para el negocio. Por eso tenés un carril oficial para informarlo: si creás una aplicación o un agente de IA, lo registrás, y cuando se vuelve importante TI lo adopta y lo formaliza bajo el estándar de ciclo de vida (SDLC) de GST. El objetivo es canalizar de una forma ordenada, segura y eficiente la creación de software.
GST gestiona la distribución del desarrollo de software con IA y la proliferación de software creado fuera del área de TI (Shadow IT o desarrollo ciudadano) mediante marcos de Gobernanza de IA Híbrida. El objetivo no es prohibir el uso de estas herramientas, sino canalizar el entusiasmo de los empleados hacia un entorno seguro.
GST mantiene el principio de catálogo único: toda herramienta de IA no aprobada está prohibida. No obstante, las herramientas de IA abren la posibilidad de un uso no gestionado del desarrollo de software. Por eso GST complementa la prohibición con un carril gestionado para el desarrollo ciudadano —aplicaciones y agentes de IA creados por usuarios fuera de TI—, de modo que el entusiasmo por la IA se canalice hacia un entorno seguro, trazable y sostenible. El objetivo no es prohibir, sino canalizar. Este modelo se apoya en tres pilares.
1 · Distribución controlada
Licencias centralizadas vía SSO, políticas de datos restrictivas y sandboxing de la ejecución.
2 · Traspaso y graduación
Cuando una herramienta se vuelve crítica, TI la adopta bajo el SDLC de GST, con QA, documentación y observabilidad.
3 · Catálogo de activos de IA
Inventario de autoservicio, niveles de criticidad e identidades para aplicaciones y agentes (NHI).
Pilar 1 · Distribución controlada de herramientas
- Licencias centralizadas: distribución por planes corporativos (Claude Enterprise/Team, GitHub Copilot Enterprise) con credenciales asignadas por TI vía SSO (Entra ID). No se permite comprar licencias individuales con tarjetas personales (fuga de propiedad intelectual).
- Políticas de datos restrictivas: cuentas empresariales con no-entrenamiento y Zero Data Retention contractuales.
- Sandboxing: como Claude Code puede ejecutar comandos en la terminal, su alcance se restringe mediante entornos aislados, evitando que altere o borre sistemas críticos por error.
Pilar 2 · Traspaso y graduación de software
El traspaso a TI y la formalización del software ciudadano se ejecutan bajo el estándar de gestión del ciclo de vida (SDLC) de GST. No es un “pase” informal: la app entra al ciclo de vida formal de la organización.
- Traspaso a TI (sustentabilidad): si la app se vuelve crítica, TI asume la custodia del código fuente y la formaliza bajo el SDLC de GST.
- Aseguramiento de calidad: análisis del código generado por IA (p. ej. SonarQube AI Code Assurance) en los pipelines, antes de producción.
- Documentación obligatoria: documentación estandarizada (área de negocio afectada, funcionalidad, arquitectura, responsables, etc.) para que cualquier desarrollador pueda analizarla, depurarla e incluirla en el SDLC de GST.
- Monitoreo y alertas: conexión a la observabilidad corporativa; alertas automáticas ante fallos o consumo anómalo de tokens.
Pilar 3 · Catálogo de activos de IA
- Portal de autoservicio e inventario: cada área registra sus herramientas internas de IA, evitando duplicación y manteniendo un mapa de riesgos claro.
- Gobernanza de identidades no humanas (NHI): cada aplicación o agente que accede a bases internas recibe una identidad única registrada; sus API keys expiran de forma periódica y no quedan expuestas en el código.
| Nivel | Alcance | Requisito de gobierno |
|---|---|---|
| 🟢 Nivel 3 — Local / Experimental | Uso individual o de equipos pequeños, sin acceso a datos restringidos. | Registro en el catálogo. |
| 🟠 Nivel 2 — Departamental | Herramientas usadas por un área entera (p. ej. un cotizador de Finanzas). | Auditoría básica de seguridad. |
| 🔴 Nivel 1 — Crítico / Corporativo | Software integrado al núcleo del negocio. | Migración obligatoria a infraestructura administrada por TI, bajo el SDLC de GST. |
Protocolo de graduación (resumen)
Detección y registro
La herramienta se registra en el catálogo de activos de IA.
Clasificación
Se asigna el nivel de criticidad (3 / 2 / 1).
Traspaso a TI
TI asume la custodia bajo el SDLC de GST.
Calidad y documentación
QA del código (SonarQube AI Code Assurance) y documentación obligatoria.
Operación
Observabilidad y alertas en producción.
Documento B · GST-23-010 Política de Uso Responsable de la IA
Emitida por Legales y Compliance (marzo 2026). Aplica a todo el Grupo Financiero ST: sociedades, accionistas, directores, comisión fiscalizadora y colaboradores — todos “Sujetos alcanzados”.
Es el reglamento ético y obligatorio de la IA en el Grupo. Define cómo debemos usarla con responsabilidad, qué se puede y qué no, cómo se aprueban las herramientas y cómo se cuidan los datos según su sensibilidad.
1. Introducción · 2. Objetivo y alcance
El Grupo reconoce la IA como una herramienta transformadora que potencia la innovación y la eficiencia, pero asume que plantea desafíos éticos, legales y de seguridad que deben abordarse con rigor. La política establece los principios y compromisos que rigen el desarrollo, implementación y uso de la IA, alineados con los valores corporativos y el marco regulatorio. Su objetivo es un marco ético y operativo que garantice un uso responsable, transparente y sostenible en todas las actividades del Grupo.
3. Principios fundamentales
Equidad y no discriminación
Los algoritmos no deben favorecer, discriminar ni perpetuar prejuicios por género, raza, edad, orientación sexual, religión u otra característica protegida.
Transparencia y trazabilidad
Los sistemas deben ser comprensibles. Si el contenido fue sustancialmente generado por IA, debe indicarse con claridad para preservar la honestidad informativa.
Seguridad y privacidad
Medidas robustas para proteger la confidencialidad, integridad y disponibilidad de los datos.
Responsabilidad
Toda producción o decisión asistida por IA debe ser revisada y validada por personas calificadas antes de su uso. La responsabilidad última recae siempre en las personas responsables de la organización.
Se sugirió especificar con más detalle quién es responsable: en lugar de “personas responsables dentro de la organización”, indicar por ejemplo “el gerente del área” u otra forma menos genérica.
4. Usos permitidos y prohibidos
✓ Permitidos (ejemplos)
- Automatización de procesos administrativos y operativos.
- Personalización de la experiencia del cliente.
- Análisis de datos para identificar tendencias y oportunidades.
- Mejora de la seguridad y prevención de riesgos.
✕ Prohibidos (entre otros)
- Procesar datos personales identificables sin consentimiento adecuado.
- Generar contenido discriminatorio, ofensivo o que infrinja derechos de autor.
- Generar enlaces que comprometan privacidad, seguridad o confianza.
- Proporcionar info privada/confidencial del Grupo (clientes, estrategias, datos financieros no públicos, PI).
- Ingresar credenciales de acceso o detalles de la infraestructura tecnológica.
- Proporcionar info de terceros no pública brindada en una relación comercial.
- Subir documentos con datos privados, confidenciales o sensibles del Grupo o de terceros.
Solo pueden emplearse herramientas de IA homologadas y autorizadas por el Área de Protección de Activos Informáticos, conforme a la sección de Homologación.
5. Homologación de herramientas
Antes de habilitar una herramienta de IA, se evalúa si conviene: seguridad, protección de datos, cumplimiento e impacto operativo. Solo las herramientas homologadas pueden usarse.
La homologación es el proceso previo que evalúa la conveniencia de habilitar una herramienta, considerando seguridad de la información, protección de datos personales, cumplimiento normativo e impacto operativo. Como resultado se determina su habilitación y las condiciones de uso. Existe un registro de herramientas habilitadas; los criterios y procedimientos se desarrollan en documentos complementarios.
Las solicitudes de homologación se canalizan a través de InvGate, desde donde se coordina la evaluación con las áreas involucradas.
En BST, aprobar una nueva herramienta podría requerir el visto de la Gerencia General y/o el Directorio según el impacto. Como esta política no llega a ese nivel de detalle, se sugiere un documento complementario para precisar esos temas normativos del banco.
6. Roles y responsabilidades
| Área | Responsabilidad en la homologación |
|---|---|
| Seguridad de la Información | Lidera la evaluación, homologación y autorización de uso de las herramientas. |
| Tecnología y/o Transformación Digital & Eficiencias | Participa en la evaluación técnica y operativa. |
| Compliance y Legales | Interviene en los aspectos regulatorios, contractuales y de protección de datos. |
Las herramientas no homologadas no pueden utilizarse en el marco de las actividades del Grupo.
Para BST, normativamente el responsable de la adopción de IA es Tecnología, por lo que debería liderar el proceso, con Seguridad evaluando y aprobando el uso. A nivel Grupo no hay objeción a que la responsabilidad esté en Seguridad, pero no queda consistente para el banco. Además, como los servicios de nuevas IA se darían desde el tenant del Grupo, podría requerirse una aclaración para los casos hosteados en el tenant de BST.
7. Gestión de riesgos
El Grupo adopta un enfoque proactivo para identificar, evaluar y mitigar riesgos del uso de IA:
Evaluaciones previas y periódicas
Identificar riesgos éticos, legales, técnicos y de seguridad antes y durante el uso de cada herramienta.
Pruebas piloto
Implementaciones controladas para garantizar sistemas seguros y efectivos.
Auditorías regulares
Verificar funcionalidad, confiabilidad y cumplimiento normativo.
Supervisión de sesgos
Monitorear y corregir sesgos con perspectivas diversas e inclusivas.
Capacitación continua
Formación específica para comprender y mitigar impactos negativos.
Procedimientos asociados
Procedimientos que detallan la identificación, evaluación y mitigación (filtraciones, inyección de datos, sesgos, indisponibilidad).
Para BST convendría agregar un riesgo “Operacional” (vinculado a procesos operativos/comerciales que usan IA), para que el Área de Riesgo pueda aprobarlo y alinearse a la normativa. También se preguntó quiénes son los responsables de las acciones del punto 7, dado que solo el banco tiene un área de riesgos de IT.
8. Protección de datos
Cuando la sensibilidad de los datos lo amerite, se implementarán medidas de privacidad y seguridad:
Anonimización
Eliminar o reemplazar identificadores directos.
Enmascaramiento
Ocultar información sensible en entornos de desarrollo o pruebas.
Cifrado
De datos sensibles en tránsito y en reposo.
Control de acceso
Estricto, basado en roles y responsabilidades.
Monitoreo continuo
Para detectar y prevenir incidentes de seguridad.
Revisión periódica
Los datos procesados por IA se revisan para cumplir normativas y estándares éticos.
Se sugirió especificar con más detalle quiénes son los responsables de la anonimización y el enmascaramiento de los datos.
9. Clasificación de la información y uso de IA
Antes de escribir algo en una IA, preguntate: ¿qué tan sensible es este dato? Cuanto más sensible, más restricciones. Ante la duda, aplicá siempre el nivel más restrictivo.
| Nivel | Uso en IA | Ejemplos |
|---|---|---|
| 🟢 Públicos | Pueden usarse libremente. | Productos en el sitio web, comunicados de prensa, info regulatoria de publicación obligatoria. |
| 🔵 Internos | Con criterio y sin exposición a terceros. | Organigramas, calendarios internos, procedimientos generales, listado de empleados. |
| 🟠 Confidenciales | Solo en herramientas homologadas y bajo condiciones controladas. | Resultados financieros no publicados, contratos con proveedores, estrategias comerciales. |
| 🔴 Sensibles | Prohibido ingresarlos, salvo autorización expresa del dueño del dato y con protección (anonimización, cifrado…). | Datos de salud, info patrimonial individual, biométricos, comunicaciones de investigaciones internas. |
Ante la duda sobre la clasificación de un dato, aplicá el nivel más restrictivo hasta que el dueño del dato defina lo contrario de manera formal. Para el detalle completo, consultá la Política de Gobierno de Datos.
10. Monitoreo · 11. Sanciones · 12. Políticas relacionadas
10 · Monitoreo y actualización
Revisión anual liderada por Transformación Digital & Eficiencias junto a Tecnología, Legales y Compliance, para alinearse con avances tecnológicos, normativa y mejores prácticas.
11 · Disciplina y sanciones
Las violaciones a políticas, leyes o reglamentaciones son objeto de medidas disciplinarias, que pueden incluir la desvinculación laboral.
12 · Políticas relacionadas
Política de Gobierno de Datos GST · Política de Privacidad y Protección de Datos Personales GST.
Documento B 💬 Observaciones de revisión (resumen)
Durante la revisión de la Política se registraron comentarios que aún están en discusión. Se listan acá para dar transparencia; no modifican el texto vigente hasta su resolución formal.
| Sección | Observación pendiente |
|---|---|
| 3 · Responsabilidad | Precisar quién es el responsable (p. ej. gerente del área) en lugar de “personas responsables dentro de la organización”. |
| 5 · Homologación | En BST podría requerirse aprobación de Gerencia General y/o Directorio; evaluar un documento complementario para el banco. |
| 6 · Roles | En BST el responsable del proceso sería Tecnología (Seguridad evalúa y aprueba); aclarar el caso de servicios hosteados en el tenant de BST. |
| 7 · Riesgos | Agregar un riesgo “Operacional” para BST e identificar responsables de las acciones del punto 7. |
| 8 · Protección de datos | Detallar los responsables de la anonimización y el enmascaramiento. |
Ayuda ❓ Preguntas frecuentes
Respuestas rápidas a las dudas más comunes mientras recorrés el texto.
¿Puedo usar ChatGPT, Gemini o Claude en su versión gratuita para el trabajo?
¿La IA usa lo que escribo para entrenarse?
¿Qué datos NO puedo cargar nunca en una IA?
Necesito una herramienta de IA que no está en el catálogo. ¿Qué hago?
¿Tengo que revisar lo que genera la IA?
Soy desarrollador: ¿puedo mergear código generado por IA directamente?
¿Quién decide si accedo a la Capa Especializada (agentes o Claude Code)?
¿Qué pasa si incumplo la política?
¿Hace falta capacitación previa?
¿La diferencia entre los dos documentos?
Creé una aplicación o agente de IA que ahora usa todo mi equipo. ¿Qué hago?
Referencia 📖 Glosario unificado
Todos los términos y siglas, explicados en lenguaje sencillo. Filtrá escribiendo abajo.
Metadatos 🗂️ Ficha de los documentos
A · Modelo de Gobierno de IA
Patrocinador: Estrategia Tecnológica GST · Dirección de Transformación & Eficiencia.
Audiencia: toda la organización GST.
Versión: 1.0 · Fecha: Junio 2026 · Buenos Aires.
Clasificación: Confidencial.
Contenido: marco general + Parte I (Áreas de Negocio) + Parte II (Desarrollo de Software) + Glosario.
B · Política de Uso Responsable (GST-23-010)
Áreas alcanzadas: todas las Áreas de las Compañías del Grupo ST.
Fecha: Marzo 2026.
Documentó: Evelyn Rocío Gallardo (Compliance).
Revisaron: Diego Di Benedetto, Paola Feller, Eduardo Vendramini.
Aprobó: Paula de la Serna (Responsable de Legales y Compliance).
Esta página es un resumen navegable de ambos documentos, creada para facilitar su lectura. En caso de discrepancia, prevalece el texto oficial de los documentos originales. Para dudas, consultas y solicitudes: InvGate.