Subtítulo: La capa invisible que determina el Riesgo y la Utilidad
Para la mayoría de los usuarios, una IA es una “Caja Negra”: un sistema opaco donde entra texto y sale magia. No sabemos qué ocurre dentro, por lo que tendemos a atribuirle cualidades humanas (“la IA piensa”, “la IA quiere”).
Este pensamiento mágico es peligroso para un Arquitecto. Si no entiendes los límites físicos de la máquina, no puedes gobernarla. En esta guía, vamos a “abrir la caja”. Vamos a desmontar el motor para entender sus componentes mecánicos: el Ciclo de Entrenamiento (cómo aprende), la Inferencia (cómo actúa) y los Parámetros (su capacidad). Dejaremos de ver magia y empezaremos a ver ingeniería.
Los modelos generativos modernos (como Gemini 3, GPT-5 o Llama 4) no son bases de conocimiento ni sistemas de razonamiento lógico en sentido humano: son motores probabilísticos de predicción, moldeados a través de múltiples fases de entrenamiento.
Este anexo describe el ciclo de vida técnico que transforma terabytes de texto crudo en un asistente capaz de seguir instrucciones. El objetivo es que el arquitecto decida en función de criterio de ingeniería, no de intuición ni del hype del mercado.
Antes de inspeccionar el motor, debemos ubicarlo en el mapa. Es común usar los términos “IA”, “Machine Learning” y “Deep Learning” indistintamente, pero son conceptos jerárquicos, como muñecas rusas (Matrioskas).
Implicancia para el Arquitecto: Cuando hablamos de “Arquitectura de IA” en esta obra, nos referimos específicamente a Deep Learning Generativo. Esto implica que no trabajamos con sistemas deterministas (reglas fijas), sino con sistemas probabilísticos (predicciones creativas pero falibles).
La generación actual se sustenta en la arquitectura Transformer (Vaswani et al., 2017). Su innovación central es el procesamiento paralelo y el Mecanismo de Atención, que asigna “pesos” de relevancia entre partes distantes de una secuencia.
Los modelos no procesan palabras, sino tokens (fragmentos numéricos).
La atención permite al modelo relacionar conceptos distantes para mantener coherencia narrativa y lógica.
El nacimiento del “Modelo Base”
Nota terminológica: En la industria, el “entrenamiento principal” del modelo se denomina Pre-Entrenamiento. Aunque el nombre parezca preliminar, esta es la fase donde realmente se construyen los pesos fundamentales. Las etapas posteriores (SFT, RLHF, RLAIF) no reemplazan esta base; la especializan.
Es la fase de mayor inversión (meses de cómputo en miles de GPUs). El modelo aprende por autosupervisión: predecir el siguiente token o completar textos masivos.
⚠️ Riesgo de Gobernanza: Implementar un Modelo Base creyendo que es un asistente produce incoherencias, sesgos sin filtrar y vulnerabilidad total a inyección de prompts.
La creación del Asistente: Esta fase convierte al motor estadístico en un sistema útil y seguro. Se divide en capas conductuales y normativas.
En esta etapa, el modelo deja de ser un simple predictor de texto (que solo quiere completar frases) para convertirse en un asistente dialogante. Se le alimenta con miles de ejemplos de alta calidad en formato (Instrucción, Respuesta Ideal) escritos por humanos expertos. Es como enviar al modelo a una “escuela de modales” donde aprende el formato de pregunta-respuesta.
Esta es la capa clásica de alineación ética y de seguridad. Dado que es imposible escribir una regla para cada situación social posible, se utiliza un sistema de “premios y castigos” basado en la preferencia humana.
El cuello de botella del RLHF son los humanos: son lentos, caros, inconsistentes y se cansan. RLAIF soluciona esto reemplazando al evaluador humano por otra IA.
La Arquitectura en Capas: Para efectos de auditoría y gestión de riesgos, visualice el modelo final no como un bloque monolítico, sino como una “lasaña” de tres capas funcionales. Cada capa aporta una capacidad específica, pero también introduce un riesgo inherente. El Arquitecto debe entender que un fallo en la capa inferior (estadística) no puede ser arreglado completamente en la capa superior (normativa); los cimientos defectuosos comprometen toda la estructura.
| Capa | Naturaleza | Función Real | Riesgo Principal |
|---|---|---|---|
| Modelo Base | Estadística | Predecir tokens | Incoherencia y falta de control. |
| SFT | Conductual | Seguir instrucciones | Alucinación confiada. |
| RLHF/RLAIF | Normativa | Alinear con valores | Rechazos falsos positivos. |
El “Arquitecto de IA” no opera basándose en comunicados de prensa o marketing. Opera basándose en evidencia técnica documentada.
La industria ha estandarizado la transparencia en dos documentos clave. Para realizar una auditoría completa de GRC, usted debe exigir y analizar ambos.
La Fórmula de Auditoría:
Viabilidad Técnica (Model Card) + Seguridad Operativa (System Card) = Aprobación de Despliegue
Documenta la Fase 1 (Pre-entrenamiento). Es el “Manual de Especificaciones Técnicas” del motor. Nos dice qué tan potente es el modelo en bruto, antes de ser alineado para seguridad.
Documenta la Fase 2 (Post-entrenamiento). Es el “Informe de Seguridad y Riesgos”. Nos dice cómo se comporta el modelo ante usuarios adversarios y qué controles tiene activados.
A continuación, se presentan las tablas de control para evaluar modelos en contextos corporativos o de contratación pública. Estas listas de verificación permiten contrastar las promesas comerciales con la realidad técnica descrita en la Model Card y la System Card.
Evaluación de capacidades fundamentales y viabilidad técnica: Esta sección evalúa la “Viabilidad Técnica”. Buscamos responder: ¿Tiene este motor la capacidad física y el conocimiento necesario para realizar la tarea?
| Pregunta de Control | Evidencia Esperada | Riesgo Asociado | Acción Mitigadora |
|---|---|---|---|
| ¿Cuál es la fecha de corte del conocimiento? | Fecha explícita. | Respuestas obsoletas; decisiones incorrectas. | Restringir dominios críticos o usar RAG (Retrieval). |
| ¿Qué arquitectura utiliza y cuántos parámetros tiene? | Descripción técnica (ej. Dense vs MoE). | Dificultad para estimar costos y latencia. | Solicitar transparencia mínima o benchmarks de inferencia. |
| ¿Cuál es el tamaño de la ventana de contexto? | Valor en tokens (ej. 128k). | Pérdida de información en tareas largas (“Olvido”). | Fragmentar tareas o usar herramientas de resumen. |
| ¿Cuáles son los resultados en benchmarks estándar? | MMLU, HumanEval. | Modelo insuficiente para tareas de razonamiento. | Escalar a un modelo más avanzado (Frontier Model). |
Evaluación de alineación, seguridad y comportamiento: Esta sección evalúa la “Seguridad y Alineación”. Buscamos responder: ¿Es seguro desplegar este modelo ante usuarios o empleados? ¿Cumple con nuestras normas de gobernanza?
| Pregunta de Control | Evidencia Esperada | Riesgo Asociado | Acción Mitigadora |
|---|---|---|---|
| ¿Qué metodología SFT se usó? | Descripción del dataset. | El modelo no sigue instrucciones de formato. | Afinar System Prompts o realizar SFT adicional. |
| ¿Existen resultados de RLHF o RLAIF? | Detalles del Reward Model. | Respuestas peligrosas, tóxicas o ideológicas. | Aplicar filtros externos (Guardrails/LOSA). |
| ¿Se documentaron pruebas de Red Teaming? | Casuística de ataques. | Fugas de información, jailbreaks exitosos. | Implementar capa adicional de seguridad de entrada/salida. |
| ¿Cuáles son las tasas de rechazo (Refusal Rates)? | Métricas de rechazo. | Negative Refusal; bloqueo injustificado de tareas. | Ajustar el modelo o cambiar proveedor si es muy restrictivo. |
Cierre del Proceso: Para finalizar la auditoría, no basta con listar hallazgos; es imperativo tomar una decisión ejecutiva documentada. Esta plantilla consolida la viabilidad técnica (proveniente de la Model Card) y la alineación de seguridad (proveniente de la System Card) en un dictamen formal. Úsela como el “sello de autorización” indispensable antes de que cualquier modelo toque infraestructura productiva o datos reales.
Fecha de Evaluación: DD/MM/AAAA
Modelo Evaluado: [Nombre del Modelo y Versión]
[Viable / No Viable][Cumple / No Cumple]Recomendación Final: [ ] APROBAR | [ ] APROBAR CON CONDICIONES | [ ] NO APROBAR
Hemos abierto el chasis y hemos visto lo que hay dentro. No hay un “espíritu” en la máquina; hay matrices de números, operaciones de punto flotante en una GPU y un ciclo de predicción estadística.
Comprender la anatomía del modelo (Entrenamiento vs. Inferencia, Parámetros vs. Contexto) es la vacuna más efectiva contra el hype.
Como “Arquitectos de IA”, este conocimiento técnico nos da poder. Dejamos de tratar a la IA como a un colega humano misterioso y empezamos a tratarla como lo que realmente es: un motor de alto rendimiento que requiere ingeniería, mantenimiento y, sobre todo, un operador competente al volante.
Ahora que entendemos el motor, estamos listos para aprender a darle instrucciones en la Guía 02: Ingeniería de Prompts.