Saltar al contenido
Henry Rincón
CV (PDF)

Métodos · Tema T4

Cómo se debe llevar un prototipo de IA a producción y mantenerlo

Se imprime completa desde el navegador, en A4 o en carta.

Bloque 1

El problema

Pasar un prototipo de IA a producción y mantenerlo sano, barato y seguro una vez publicado.

Síntesis en tres líneas

  1. Un prototipo pasa a producción cuando supera condiciones escritas que ya se vieron fallar. Los controles que corren antes de publicar son las pruebas unitarias, de integración y de extremo a extremo, la accesibilidad, el rendimiento y el bloqueo de secretos, y si hay un modelo, preguntas de prueba que corren en cada cambio como cualquier otra prueba.
  2. Antes de la IA va el código: el modelo entra solo donde una regla no alcanza, detrás de una capa que permite cambiar de proveedor y con una salida más simple, anunciada, para cuando falla.
  3. Publicar es el comienzo de la validación: se mantiene con metadatos y no con el contenido de quien lo usa, con límites y un techo de costo escritos, y con un resumen de cada ciclo que convierte la falla en regla.
Bloque 2

El mapa

Del prototipo a producción, y de producción a la siguiente versión

Desliza para ver el mapa completo.

Del prototipo a producción, y de producción a la siguiente versiónUn prototipo empieza con una decisión escrita: si necesita un modelo, por qué una regla no basta. Después cruza los controles de publicación —pruebas en tres niveles, accesibilidad, rendimiento y, si hay modelo, preguntas de prueba—, el bloqueo de secretos y la revisión de dependencias. Con todo en verde, el cambio se despliega en una vista previa propia, una persona la revisa y decide publicarlo. En producción, sin servidor propio, el producto llama al modelo a través de una capa que cambia de proveedor por configuración; los límites y el techo de costo acotan esas llamadas, y si el proveedor falla, el producto ofrece una función más simple y se lo dice a quien lo usa. La operación deja metadatos —no contenido— y cada ciclo cierra con un resumen y una decisión registrada, de donde parte la versión siguiente.Prototipo1Decisión escrita2Pruebas yevaluaciones3Secretos ydependencias4Vista previa porcambio5Quien aprueba6Producción sinservidor propio7Capa de proveedor8Degradaciónanunciada9Límites y techode costo10Metadatos, nocontenido11Resumen del ciclo12Quien usa elproducto13

Leyenda de formas y colores

  • Actor — quien hace el trabajo
  • Dato — lo que se guarda y se lee
  • Control — una regla que se comprueba
  • Persona — una persona decide
  • Externo — lo que viene de afuera

Lectura del mapa, nodo por nodo

Un prototipo empieza con una decisión escrita: si necesita un modelo, por qué una regla no basta. Después cruza los controles de publicación —pruebas en tres niveles, accesibilidad, rendimiento y, si hay modelo, preguntas de prueba—, el bloqueo de secretos y la revisión de dependencias. Con todo en verde, el cambio se despliega en una vista previa propia, una persona la revisa y decide publicarlo. En producción, sin servidor propio, el producto llama al modelo a través de una capa que cambia de proveedor por configuración; los límites y el techo de costo acotan esas llamadas, y si el proveedor falla, el producto ofrece una función más simple y se lo dice a quien lo usa. La operación deja metadatos —no contenido— y cada ciclo cierra con un resumen y una decisión registrada, de donde parte la versión siguiente.

  1. Nodo 1 Prototipo (Dato) — Algo que ya funciona en una máquina: todavía no es un producto.
  2. Nodo 2 Decisión escrita (Control) — Código primero: un modelo entra solo con una decisión de arquitectura que diga qué no resuelve una regla.
  3. Nodo 3 Pruebas y evaluaciones (Control) — Unitarias, de integración y de extremo a extremo, accesibilidad, rendimiento y, si hay modelo, preguntas de prueba: todas en cada cambio.
  4. Nodo 4 Secretos y dependencias (Control) — Un secreto se bloquea antes de entrar al historial; una dependencia vulnerable frena el cambio.
  5. Nodo 5 Vista previa por cambio (Dato) — Cada cambio se despliega aparte y se mira antes de llegar a producción.
  6. Nodo 6 Quien aprueba (Persona) — Una persona revisa la vista previa y, con cada control requerido en verde por sí mismo, decide publicar.
  7. Nodo 7 Producción sin servidor propio (Externo) — Páginas estáticas, funciones en el borde y una base gestionada con seguridad por filas: nada que operar a mano.
  8. Nodo 8 Capa de proveedor (Actor) — El único módulo que conoce proveedores concretos: una variable elige cuál, y fallas seguidas abren el circuito.
  9. Nodo 9 Degradación anunciada (Control) — Sin proveedor, el producto ofrece una función más simple que conserva lo esencial, y lo dice.
  10. Nodo 10 Límites y techo de costo (Control) — Frecuencia, tamaño, tokens, tiempo e historial escritos como números, y un presupuesto mensual que no decide solo la factura.
  11. Nodo 11 Metadatos, no contenido (Control) — Proveedor, modelo, milisegundos, tokens y errores: lo necesario para saber qué falló, dónde y cuánto costó.
  12. Nodo 12 Resumen del ciclo (Dato) — Cada ciclo cierra con lo que falló y por qué; una falla que se repite se vuelve regla con su prueba.
  13. Nodo 13 Quien usa el producto (Persona) — Recibe la respuesta completa o la función simple, y en los dos casos sabe cuál recibió.

Conexiones

  • de Prototipo a Decisión escrita (se justifica)
  • de Decisión escrita a Pruebas y evaluaciones
  • de Pruebas y evaluaciones a Secretos y dependencias
  • de Secretos y dependencias a Vista previa por cambio (todo en verde)
  • de Vista previa por cambio a Quien aprueba (se revisa)
  • de Quien aprueba a Producción sin servidor propio (publica)
  • de Producción sin servidor propio a Capa de proveedor (llama al modelo)
  • de Límites y techo de costo a Capa de proveedor (acota)
  • de Capa de proveedor a Degradación anunciada (si falla)
  • de Degradación anunciada a Quien usa el producto (lo dice)
  • de Producción sin servidor propio a Metadatos, no contenido (deja)
  • de Metadatos, no contenido a Resumen del ciclo (se aprende)
  • de Resumen del ciclo a Prototipo (siguiente versión)
Bloque 3

Las fases

  1. Fase 1

    Decidir si hace falta un modelo

    Entradas

    • El problema y el proceso donde vive.
    • Lo que una regla, una búsqueda o un algoritmo ya resuelven.

    Actividades

    • Escribir qué parte exige interpretar, generar, recuperar por contexto o coordinar herramientas.
    • Resolver primero con código lo que el código resuelve.
    • Dejar la decisión registrada, con lo que el modelo no debe hacer.

    Artefactos

    • Una decisión de arquitectura escrita.
    Quién decide
    Quien responde por el producto.
    Control que cierra la fase
    Sin decisión escrita, la función generativa no se activa.
    Evidencia

    En las apps del autor, activar una función generativa exige una decisión de arquitectura escrita: Innmobiliaria tiene cero modelos por regla de producto, y donde sí hay uno es opcional y con un fallback determinista.

  2. Fase 2

    Convertir el prototipo en algo verificable

    Entradas

    • El prototipo.
    • Las condiciones de publicación, escritas.

    Actividades

    • Pruebas unitarias, de integración y de extremo a extremo; accesibilidad y presupuesto de rendimiento.
    • Si hay modelo: preguntas de prueba y casos donde debe abstenerse, declarar que no sabe o rechazar.
    • Ver fallar cada control nuevo frente a lo que pretende atrapar, antes de darlo por bueno.

    Artefactos

    • La suite en la integración continua.
    • La demostración en rojo de cada control nuevo.
    Quién decide
    Quien construye.
    Control que cierra la fase
    Un control nuevo entra solo después de verse fallar.
    Estado del campo

    Microsoft recomienda incorporar pruebas cualitativas en los pipelines de publicación, porque la IA no es determinista, y que el monitoreo alimente las puertas de calidad en todo el ciclo.[8]

  3. Fase 3

    Proteger lo que se publica

    Entradas

    • El repositorio, que puede ser público.
    • Las credenciales del proveedor y de la base de datos.

    Actividades

    • Bloquear los secretos antes del commit y probar ese bloqueo con una carnada que sí lo dispara.
    • Dejar las claves solo en las variables de entorno del despliegue, nunca en el código que llega al navegador.
    • Probar cada credencial antes de construir contra ella.
    • Auditar las dependencias y actualizarlas en lotes pequeños, verificados uno a uno.

    Artefactos

    • El bloqueo de secretos y su carnada verificada.
    • La configuración del entorno, fuera del repositorio.
    Quién decide
    Quien construye.
    Control que cierra la fase
    Un commit con un secreto no llega a existir.
    Estado del campo

    GitHub activó por defecto la protección contra secretos en los push a repositorios públicos: si detecta uno, bloquea el push hasta que se quite o se decida pasarlo por alto.[9]

  4. Fase 4

    Llevarlo a producción: corren los controles antes de publicar y una persona decide

    Entradas

    • La vista previa del cambio.
    • Las conclusiones de cada control requerido.

    Actividades

    • Revisar la vista previa como la verá quien la usa.
    • Comprobar que cada control requerido corrió y terminó en verde por sí mismo: uno saltado no es verde.
    • Publicar desde la rama principal, con la versión anterior a la mano para volver.

    Artefactos

    • El cambio en producción.
    • Una forma de volver a la versión anterior.
    Quién decide
    Quien es dueño del producto.
    Control que cierra la fase
    Ningún control requerido saltado ni en rojo.
    Evidencia

    A cada control se le hacen tres preguntas antes de darlo por bueno: ¿se vio fallar?, ¿se vio correr? —un job saltado no es verde— y ¿puede fallar siquiera?

  5. Fase 5

    Operar: medir, acotar y degradar

    Entradas

    • El uso real.
    • El presupuesto escrito.

    Actividades

    • Registrar metadatos estructurados y reportar los errores, sin el contenido de quien usa el producto.
    • Poner límites de frecuencia, longitud, salida, tiempo e historial.
    • Abrir el circuito tras fallas seguidas y pasar a la función simple, diciéndolo.
    • Tener un interruptor que apague la función generativa sin tumbar el resto.

    Artefactos

    • Registros estructurados y alertas de errores.
    • El modo degradado, probado.
    Quién decide
    Quien paga y responde por la operación.
    Control que cierra la fase
    Con el proveedor caído, el producto sigue cumpliendo lo esencial y lo dice.
    Evidencia

    En el chat de este sitio, tras tres fallas consecutivas el circuito se abre y el navegador busca en el mismo índice, diciendo que no es una respuesta del modelo.

  6. Fase 6

    Aprender y empezar la siguiente versión

    Entradas

    • Las fallas, las mediciones y lo que encontró quien usa el producto.

    Actividades

    • Escribir el resumen del ciclo: qué se hizo, qué falló y qué quedó pendiente.
    • Convertir el incidente en una regla con su prueba, no en una anécdota.

    Artefactos

    • El resumen y la decisión registrada.
    • La regla nueva y su demostración en rojo.
    Quién decide
    Quien es dueño del método.
    Control que cierra la fase
    Sin resumen escrito, el ciclo no cierra.
    Evidencia

    En el sprint 3 de este sitio una credencial del proveedor devolvió un 401 en la integración; desde entonces toda credencial pasa una prueba de humo antes de construir contra ella, y la integración continua la repite en cada corrida.

Bloque 4

Las decisiones de diseño

  1. Código primero o un modelo

    Cuándo sí
    Un modelo, cuando el problema exige interpretar, generar, recuperar por contexto o coordinar herramientas con flexibilidad, y una regla no alcanza.
    Cuándo no
    Cuando una regla, una búsqueda estructurada o un algoritmo cumplen el propósito: son más previsibles, más baratos y más fáciles de probar.

    Por qué

    Evidencia

    Es la regla 13 del pipeline del autor: antes de usar IA generativa se demuestra qué característica del problema la exige, y activarla pide una decisión de arquitectura escrita.

    Criterio

    La pregunta no es si se puede meter IA, sino si la mejora justifica lo que trae: dependencias, costo, variabilidad y una evaluación que alguien tiene que sostener.

  2. Un proveedor fijo o una capa que lo cambia

    Cuándo sí
    Una capa conmutable, cuando el producto debe sobrevivir a que un modelo se retire, una cuota cambie o un proveedor se caiga.
    Cuándo no
    Un proveedor fijo, cuando la función depende de algo que solo uno ofrece y esa dependencia se acepta por escrito.

    Por qué

    Evidencia

    En el chat una variable de entorno elige entre cinco proveedores adaptados, y una capa de adaptación es el único módulo que los conoce: cambia quien redacta, no el índice ni los hechos.

    Criterio

    Cambiar de proveedor es fácil cuando el conocimiento no vive en él; lo que hay que probar es que el nuevo conserve las citas, los rechazos y el tamaño de la respuesta.

  3. Qué se evalúa en cada cambio y qué se revisa a mano

    Cuándo sí
    En cada cambio, lo que se mide de forma barata y determinista: que la recuperación traiga su fuente, que los destinos existan, que las preguntas ajenas se corten.
    Cuándo no
    Un juez con modelo en cada commit, cuando cuesta más de lo que protege: ahí va por lotes, antes de publicar.

    Por qué

    Estado del campo

    Microsoft documenta, en vista previa, una acción de GitHub que evalúa agentes dentro de la integración continua, con intervalos de confianza y pruebas de significancia para saber si un cambio mejoró o solo varió, y aconseja no correrla en cada commit para contener el costo.[3]

    Evidencia

    En este sitio la recuperación se evalúa en cada cambio con preguntas propias y de afuera; la respuesta que intenta meter algo no recuperado la caza hoy la lectura, no un gate.

  4. Contenedores propios o despliegue sin servidor

    Cuándo sí
    Sin servidor propio, cuando el producto es estático o de funciones cortas y nadie debería tener que operar una máquina: el borde y el navegador alcanzan.
    Cuándo no
    Cuando la carga pide procesos largos, estado en memoria o un control del entorno que la plataforma no da: ahí un contenedor paga lo que cuesta operarlo.

    Por qué

    Evidencia

    Los despliegues del autor son sin servidor propio —Vercel, Cloudflare Workers, el navegador del usuario— y por eso nunca han necesitado un contenedor.

    Estado del campo

    Para desplegar un modelo, Microsoft recomienda empezar por plataforma como servicio y soluciones sin servidor para simplificar la adopción y la operación; el cómputo gestionado es una opción viable para necesidades avanzadas, y el autoalojamiento, otra opción.[8]

  5. Qué se guarda para observar

    Cuándo sí
    Metadatos —proveedor, modelo, milisegundos, tokens, errores— para saber qué falló, dónde y cuánto costó.
    Cuándo no
    El contenido de quien usa el producto, salvo que el producto lo necesite, se diga antes de la primera palabra y tenga su decisión registrada.

    Por qué

    Evidencia

    En las apps del autor lo que se observa viaja como metadatos por Pino y Sentry; el chat de este sitio sí guarda pregunta y respuesta desde el 21 de septiembre de 2026, y lo advierte antes de que el visitante escriba.

    Estado del campo

    Microsoft Foundry (antes Azure AI Foundry) traza cada llamada al modelo y a las herramientas sobre el estándar OpenTelemetry, y su monitoreo de producción sigue consumo de tokens, latencia, tasa de errores y calidad, con alertas cuando una salida no pasa sus umbrales.[2]

Bloque 5

Lo innovador en 2026

  • Estado del campo

    Microsoft Foundry, una plataforma que junta evaluar, observar y poner barreras

    Qué cambia frente a la práctica común

    Microsoft Foundry reúne agentes, modelos y herramientas en un solo recurso, con trazas, monitoreo y evaluaciones incorporados; sus barreras de seguridad pueden revisar la entrada, la salida y, para agentes y en vista previa, la llamada a una herramienta y su respuesta.[1][12]

    Evidencia

    La experiencia del autor con Microsoft Foundry —sus límites, en el bloque 9—: se conectó al chat como uno de sus proveedores, y su temario se estudia en la ruta del AI-103, que está en curso.

  • Estado del campo

    Las evaluaciones como una prueba más del pipeline

    Qué cambia frente a la práctica común

    La observabilidad deja de empezar en producción: Foundry integra puertas de calidad automáticas en la integración continua (con una acción de GitHub en vista previa), aplica evaluadores de calidad, de RAG y de seguridad a un conjunto de consultas, y después evalúa una muestra del tráfico real.[2][3]

    Evidencia

    En este sitio las preguntas de prueba ya corren en cada cambio como cualquier otra prueba; para la respuesta del modelo no hay un juez automático.

  • Estado del campo

    Atacarse a uno mismo antes de publicar

    Qué cambia frente a la práctica común

    El agente de red teaming de Foundry prueba la aplicación con estrategias de ataque de PyRIT y mide la tasa de ataques exitosos; Microsoft advierte que el juez es generativo, que puede dar falsos positivos y que los resultados se revisan antes de actuar.[4]

    Criterio

    Conviene correrlo antes de abrir al público una función generativa nueva, y leer los ataques que pasaron antes de tocar un solo filtro.

  • Estado del campo

    Mandar cada pedido al modelo que alcanza

    Qué cambia frente a la práctica común

    El enrutador de modelos de Foundry analiza cada pedido y lo manda a un modelo pequeño cuando basta y a uno de frontera cuando lo exige; dice qué modelo respondió, y Microsoft aclara que no quita la necesidad de evaluar.[5]

    Evidencia

    El ahorro del chat de este sitio ocurre antes del modelo: las preguntas fuera de alcance no consumen tokens y solo viajan los fragmentos relevantes, no el sitio entero.

  • Estado del campo

    Reutilizar el principio del prompt

    Qué cambia frente a la práctica común

    Si los primeros 1.024 tokens de un pedido son idénticos a uno anterior, el servicio reutiliza el cómputo y cobra con descuento esa lectura; por eso lo estable va al principio y lo que cambia, al final.[6]

    Criterio

    Es una palanca cuando las instrucciones son largas y se repiten idénticas; antes de contar con ella conviene medir cuánto del pedido es de verdad estable.

  • Estado del campo

    El consumo sin límite, tratado como riesgo de seguridad

    Qué cambia frente a la práctica común

    El Top 10 de OWASP para aplicaciones con LLM de 2025 trata el consumo sin control como riesgo —denegación de servicio, pérdidas económicas— y pide validar el tamaño de las entradas, limitar la frecuencia por usuario o entidad, poner tiempos máximos y vigilar el uso de recursos.[10]

    Evidencia

    El chat de este sitio tiene esos límites escritos como números y no como intenciones: 800 caracteres por pregunta, 700 tokens de salida, 30 segundos y 12 mensajes de historial.

  • Estado del campo

    La cadena de suministro también es la de la IA

    Qué cambia frente a la práctica común

    OWASP extiende la cadena de suministro a modelos, datos y plataformas, y pide revisar a los proveedores, mantener un inventario de componentes al día —una lista de materiales de software— y una política de parches para lo vulnerable o desactualizado.[11]

    Evidencia

    Anonimizador Velo audita sus dependencias en la integración continua contra tres familias vetadas de SDK de IA, y una dependencia transitiva cuenta igual que una directa.

  • Estado del campo

    Operar IA ya es una certificación

    Qué cambia frente a la práctica común

    La guía de estudio de Microsoft para su certificación de operaciones de aprendizaje automático y de IA generativa pide versionar los prompts en Git, montar evaluaciones automáticas con métricas de calidad y de seguridad, y seguir el costo en tokens junto a la latencia y el rendimiento.[7]

    Evidencia

    La ruta del AI-300 se sigue desde julio de 2026; está en curso y no se presenta como obtenida.

Bloque 6

Modos de falla y cómo anticiparlos

  • Qué se rompe
    Un control que siempre da verde
    Cómo se ve venir
    Nadie lo vio fallar; un job saltado aparece entre los requeridos sin alarma.
    Control que la atrapa
    La demostración en rojo viaja en el mismo commit que el control, y cada verificación requerida tiene su propia conclusión.
  • Qué se rompe
    Un secreto llega al repositorio
    Cómo se ve venir
    Una clave en un commit, en un registro o en el código que llega al navegador.
    Control que la atrapa
    Barrido de secretos antes del commit, probado con una carnada que sí lo dispara; claves solo en el entorno del despliegue.
  • Qué se rompe
    Una credencial inválida se descubre al final
    Cómo se ve venir
    El primer uso real devuelve un 401.
    Control que la atrapa
    Prueba de humo de cada credencial antes de construir contra ella, repetida en la integración continua.
  • Qué se rompe
    El proveedor se cae, se queda sin cuota o retira el modelo
    Cómo se ve venir
    Fallas seguidas, tiempos vencidos, un modelo que deja de existir.
    Control que la atrapa
    Capa de proveedor conmutable, cortacircuitos y una función degradada que se anuncia como tal.
  • Qué se rompe
    El costo crece sin que nadie lo decida
    Cómo se ve venir
    Más tokens por respuesta, pedidos ajenos que llegan al modelo, picos de un solo origen.
    Control que la atrapa
    Un filtro antes del modelo, límites de frecuencia y tamaño, y un techo de costo escrito.
  • Qué se rompe
    La calidad se degrada en silencio después de publicar
    Cómo se ve venir
    Reintentos que se acumulan con una integración, respuestas que dejan de citar, latencia que sube.
    Control que la atrapa
    Telemetría por sesión con metadatos y las preguntas de prueba corriendo contra cada cambio.
  • Qué se rompe
    Una dependencia vulnerable o desactualizada
    Cómo se ve venir
    Un aviso de seguridad, o un paquete que baja de versión sin que nadie lo pida.
    Control que la atrapa
    Auditoría de dependencias en la integración continua y actualizaciones en lotes pequeños, cada uno verificado.
  • Qué se rompe
    La telemetría se lleva datos de quien usa el producto
    Cómo se ve venir
    Contenido de un usuario en un registro o en un error reportado.
    Control que la atrapa
    Registro estructurado solo con metadatos; lo que sí se guarda se declara antes y tiene su decisión escrita.
Bloque 7

Métricas y controles

  • Qué se mide
    Controles requeridos con conclusión propia en verde
    Umbral
    Todos; uno saltado cuenta como no verde.
    Quién aprueba el paso a producción
    Quien publica, leyendo cada conclusión.
  • Qué se mide
    Controles nuevos vistos fallando
    Umbral
    Todos, antes de entrar.
    Quién aprueba el paso a producción
    Quien construye, con la demostración registrada.
  • Qué se mide
    Preguntas de prueba con su fuente entre las que entran
    Umbral
    Un piso escrito que no baja de un cambio al siguiente.
    Quién aprueba el paso a producción
    Quien es dueño del contenido.
  • Qué se mide
    Secretos en el historial
    Umbral
    Cero: uno solo detiene el commit.
    Quién aprueba el paso a producción
    El bloqueo de secretos, sin excepciones.
  • Qué se mide
    Costo mensual frente al techo escrito
    Umbral
    Por debajo del techo; si se acerca, se recorta contexto y extensión antes de cambiar de modelo.
    Quién aprueba el paso a producción
    Quien paga la operación.
  • Qué se mide
    Latencia y errores del proveedor
    Umbral
    Dentro del tiempo máximo por pedido; fallas seguidas abren el circuito.
    Quién aprueba el paso a producción
    Quien responde por el producto.
  • Qué se mide
    Función esencial con el proveedor caído
    Umbral
    Disponible y rotulada como degradada.
    Quién aprueba el paso a producción
    Quien responde por el producto.
  • Qué se mide
    Contenido de usuarios en la telemetría
    Umbral
    Cero.
    Quién aprueba el paso a producción
    Quien responde por los datos.

Los umbrales son ejemplos del método, no cifras de un proyecto concreto.

Bloque 8

Evidencia en proyectos

  • EvidenciaNivel: Uso real

    La cadena de publicación que comparten las apps del autor

    Las aplicaciones hermanas y este sitio comparten criterios y, en lo esencial, esta cadena: Git y GitHub, integración continua con pruebas unitarias, de integración y de extremo a extremo, accesibilidad con axe, presupuesto de rendimiento con Lighthouse y despliegue en Vercel con una vista previa por cambio (Innmobiliaria sale desde el borde en Cloudflare Workers y Dash Agent no se despliega); ninguna rama llega a producción con uno de esos trabajos en rojo.

    Ver dónde
  • EvidenciaNivel: Uso real

    Este sitio: la integración continua contra una base real

    El trabajo de integración levanta un Supabase real, le aplica las migraciones y prueba contra Postgres; un permiso de la base se da por verificado cuando una prueba intenta saltárselo y no puede.

    Ver dónde
  • EvidenciaNivel: Uso real

    Un control se demuestra fallando

    Cada control nuevo trae en el mismo commit su demostración en rojo. La regla nació el 15 de julio de 2026, cuando el barrido de secretos pasó en silencio dos veces con una carnada floja: desde entonces la carnada canónica está verificada.

  • EvidenciaNivel: Uso real

    La capa de proveedor y la degradación, probadas en una falla real

    Una variable de entorno elige el proveedor del chat. En el sprint 3 una credencial devolvió un 401 en la integración, el circuito se abrió y la búsqueda local respondió sobre el mismo índice, diciendo que no era una respuesta del modelo.

    Ver dónde
  • EvidenciaNivel: Uso real

    Un techo de costo y el costo medido

    El chat opera con un techo de US$20 al mes y un costo real observado de US$0, porque el uso cabe en la cuota gratuita del proveedor inicial y las consultas ajenas se resuelven sin invocarlo: es una medición, no una promesa de gratuidad.

  • EvidenciaNivel: Uso real

    Observar agentes en producción

    En Vesting se diseñó la plataforma que observaba hasta 23 agentes a la vez en producción: los eventos viajaban a Microsoft Fabric y de ahí a Power BI, y la telemetría por sesión mostró a un agente que acumulaba reintentos antes de que un usuario lo reportara.

    Ver dónde
  • EvidenciaNivel: Uso real

    Datos con seguridad por filas y acceso solo por funciones

    La base de este sitio tiene la seguridad por filas encendida y sin políticas: el rol anónimo solo ejecuta funciones con privilegios del definidor, y la llave de servicio no viaja al navegador ni vive en el repositorio.

  • EvidenciaNivel: Uso real

    Modelos en producción, sostenidos

    La mitad de MLOps que consiste en llevar modelos a producción y sostenerlos está hecha: modelos predictivos en Banco Pichincha y en TransMilenio, el monitoreo de agentes en Vesting y aplicaciones públicas con integración continua y despliegue automático, operadas por el autor.

Bloque 9

Límites y alcance

  • Evidencia

    Contenedores en producción con Docker y Kubernetes no están en la experiencia del autor: Kubernetes se conoce por estudio, no por operación, y la mitad de MLOps que empaqueta y orquesta con contenedores no está hecha.

  • Evidencia

    Con Microsoft Foundry la experiencia es el adaptador de proveedor de este chat, ajustes de modelos hechos ahí, en varios prototipos propios, y el estudio del AI-103, que está en curso; no se describe ningún despliegue propio en Azure.

  • Evidencia

    El AI-300 está en curso: es la certificación de operar modelos y agentes, y no se presenta como obtenida.

  • Evidencia

    La respuesta del modelo todavía se revisa leyendo: la que intenta introducir información no recuperada la caza la lectura, no un gate.

  • Evidencia

    Las fases de lanzamiento y de operación de la fábrica de apps del autor siguen sin validarse en una corrida real: son método escrito, no experiencia.

  • Criterio

    Lo que conviene hacer distinto hoy: la evaluación con un juez calibrado como un trabajo más de la integración continua desde el primer sprint con IA, y un red teaming automatizado antes de abrir una función generativa al público.

  • Criterio

    Y no conviene empezar por la plataforma: mejor empezar por las condiciones de publicación, escritas y vistas fallar; la plataforma se elige después, por lo que esas condiciones necesitan.

Bloque 10

Fuentes y fecha de revisión

  1. [1]
    What is Microsoft Foundry?

    Microsoft Learn ·

    https://learn.microsoft.com/en-us/azure/foundry/what-is-foundry

  2. [2]
    Observability in Generative AI

    Microsoft Learn ·

    https://learn.microsoft.com/en-us/azure/foundry/concepts/observability

  3. [3]
    How to run an evaluation in GitHub Action

    Microsoft Learn ·

    https://learn.microsoft.com/en-us/azure/foundry/how-to/evaluation-github-action

  4. [4]
    AI Red Teaming Agent

    Microsoft Learn ·

    https://learn.microsoft.com/en-us/azure/foundry/concepts/ai-red-teaming-agent

  5. [5]
    How model router works in Microsoft Foundry

    Microsoft Learn ·

    https://learn.microsoft.com/en-us/azure/foundry/openai/concepts/model-router-how-it-works

  6. [6]
    Prompt caching with Azure OpenAI in Microsoft Foundry Models

    Microsoft Learn ·

    https://learn.microsoft.com/en-us/azure/foundry/openai/how-to/prompt-caching

  7. [7]
    Study guide for Exam AI-300: Operationalizing Machine Learning and Generative AI Solutions

    Microsoft Learn ·

    https://learn.microsoft.com/en-us/credentials/certifications/resources/study-guides/ai-300

  8. [8]
    MLOps and GenAIOps for AI Workloads on Azure (Azure Well-Architected Framework)

    Microsoft Learn ·

    https://learn.microsoft.com/en-us/azure/well-architected/ai/mlops-genaiops

  9. [9]
    Keeping secrets out of public repositories

    GitHub ·

    https://github.blog/news-insights/product-news/keeping-secrets-out-of-public-repositories/

  10. [10]
    LLM10:2025 Unbounded Consumption (OWASP Top 10 for LLM Applications 2025)

    OWASP GenAI Security Project ·

    https://genai.owasp.org/llmrisk/llm102025-unbounded-consumption/

  11. [11]
    LLM03:2025 Supply Chain (OWASP Top 10 for LLM Applications 2025)

    OWASP GenAI Security Project ·

    https://genai.owasp.org/llmrisk/llm032025-supply-chain/

  12. [12]
    Guardrails and controls overview in Microsoft Foundry

    Microsoft Learn ·

    https://learn.microsoft.com/en-us/azure/foundry/guardrails/guardrails-overview