Laboratorio de coinnovación de Microsoft: creación rápida de prototipos en el SoTA de la IA

Durante el año pasado, la velocidad vertiginosa del avance de la IA nos obligó a aceptar una realidad un tanto incómoda: la solución técnica que hoy consideramos óptima probablemente quede obsoleta dentro de seis meses. En Marvik, llevamos trabajando junto a Microsoft en el laboratorio de innovación conjunta de Uruguay desde 2023, desarrollando prototipos rápidos para proyectos en una amplia gama de sectores, desde la tecnología agrícola hasta la sanitaria. Con el tiempo, hemos pasado de diseñar arquitecturas modulares complejas a ver cómo las nuevas herramientas, modelos y plataformas integradas simplifican las soluciones en un abrir y cerrar de ojos. Esta dinámica exige no solo agilidad técnica, sino también un cambio fundamental de mentalidad..

En el Laboratorio de Coinnovación de Microsoft, nuestra dinámica se basa en la experimentación constante. Nuestro objetivo es acelerar el desarrollo de productos de IA, centrándonos en las primeras etapas críticas del modelado de soluciones. Esta posición nos otorga una perspectiva privilegiada, y a veces vertiginosa, sobre cómo los avances tecnológicos pueden cambiar por completo la forma en que abordamos un problema.

En este blog, analizamos tres casos de uso que abordamos en diferentes etapas durante el año pasado. Analizaremos cómo las soluciones que inicialmente requerían arquitecturas complejas se rediseñaron meses después utilizando herramientas, modelos o plataformas de última generación. Más allá del cambio técnico, compartimos nuestra evaluación del equilibrio entre eficiencia, control y costo.

¿Por qué es importante?

Documentar esta evolución no es solo un ejercicio de nostalgia técnica; es una necesidad estratégica por tres razones:

1. Gestión de expectativas: Comprender que la solución más reciente no siempre es la más sólida para un entorno de producción.
2. Arquitecturas con fecha de caducidad: Aceptar que el diseño que implementamos hoy, sin importar cuán optimizado esté, podría quedar obsoleto en meses. Esto obliga a cambiar nuestro enfoque: diseñar soluciones flexibles que puedan sustituirse por herramientas más eficientes sin dañar todo el ecosistema.‍
3. Redefinición de roles: Adaptar las capacidades de nuestro equipo a un mundo en el que el diseño de soluciones tiene más peso que la escritura de código.

Caso práctico 1: Contraste automatizado de documentos

Una empresa farmacéutica necesitaba comparar dos documentos para cada medicamento que lanzaba al mercado: un PDF con el diseño de la etiqueta impresa, incluidas las instrucciones de diseño y formato, y un archivo de Word con la información médica oficial que debía figurar en él. Cualquier discrepancia entre los dos constituía un riesgo regulatorio. El proceso se hizo totalmente a mano.

El desafío no era solo la comparación en sí misma. El PDF era un archivo de diseño visual, no un texto plano, lo que significaba que el contenido podía aparecer en un orden diferente al del documento de Word. Antes de poder realizar cualquier comparación, ambos archivos debían extraerse, normalizarse y hacerse compatibles.

Construimos un oleoducto modular. Azure Document Intelligence se encargó de extraer ambos archivos y convirtió el PDF en contenido estructurado que podía compararse con el texto normalizado de Word. A continuación, dividimos ambos documentos semánticamente y los indexamos con Azure AI Search, lo que nos permitió recuperar solo las secciones más relevantes antes de enviarlas a un modelo lingüístico para compararlas. Esto redujo el riesgo de errores encadenados debidos a la fragmentación automática o a la mala lectura de los PDF..

El resultado fue una lista estructurada de discrepancias, cada una de las cuales se asignó a su ubicación exacta en el PDF original con las coordenadas de los recuadros delimitadores, de modo que el equipo regulador pudiera ver las secciones marcadas resaltadas directamente en el diseño de la etiqueta. El oleoducto funcionó bien. También requirió la organización de varios servicios y una cantidad significativa de código personalizado.

Azure Content Understanding llegó con la promesa de agrupar gran parte de eso en un solo servicio integrado. Lo hemos probado. Gestionó bien algunos casos, pero introdujo errores en otros que la canalización modular detectó de forma fiable. En un contexto regulatorio, en el que una discrepancia no detectada no es solo un error sino una falta de cumplimiento, no era una compensación que pudiéramos aceptar.

Este caso no terminó cuando cambiamos a la herramienta más simple. Al final nos quedamos con la más compleja, y ese es el punto. La promesa de soluciones integradas es real, pero no todos los problemas pueden darse el lujo de cambiar precisión por conveniencia. Cuando el costo de un error omitido es lo suficientemente alto, la visibilidad que le brinda una canalización modular, la capacidad de inspeccionar el texto extraído, los fragmentos recuperados y los resultados del modelo como artefactos independientes, no es una sobrecarga. Es el producto.

La comprensión del contenido aún está en versión preliminar. Lo revisaremos.

Estudio de caso 2: Agentes conversacionales de voz

Sin lugar a dudas, la popularidad de los agentes de chat explotó durante la segunda mitad de 2025. Naturalmente, el siguiente paso fue el agente de voz conversacional. En el laboratorio, abordamos nuestro primer caso de agente conversacional en agosto de 2025. El objetivo del cliente era crear un agente capaz de entrevistar a un usuario a través de una llamada telefónica y recopilar datos para evaluar si era un candidato potencial para obtener un crédito.

El contexto de 2025

Cuando abordamos este caso, decidimos probar dos métodos diferentes: el primero, y el más innovador, utilizó la solución STS (Speech-to-Speech) de Azure a través de la API Voice Live; el segundo enfoque, el más clásico, utilizó una canalización modular de STT → Reasoning LLM → TTS con Azure Speech Services.

El primer enfoque prometía una solución más sencilla y una implementación más rápida, ya que solo se requieren unas pocas líneas de código para configurar una sesión y realizar una llamada a la API. Sin embargo, a medida que avanzamos con la prueba de concepto (PoC), nos dimos cuenta rápidamente de que la alta latencia y la voz robótica del agente hacían que la experiencia de usuario fuera deficiente, hasta el punto de que no podíamos mantener una conversación sin silencios incómodos entre los interlocutores o incluso durante el discurso del agente. Desde el punto de vista del desarrollo, el diseño de caja negra de la API hacía que fuera extremadamente difícil rastrear dónde estaba el cuello de botella, ya que no teníamos acceso al proceso subyacente. En nuestra opinión, el producto aún no estaba en un estado en el que pudiera ampliarse o considerarse fiable para la producción.

Debido a esto, decidimos volver al diseño más tradicional, dividiendo la tarea en sus bloques fundamentales, que se muestran en el siguiente diagrama.

Esto nos dio más control sobre la latencia, los detalles de rendimiento y los costos generales de la solución. Finalmente pudimos determinar que la alta latencia de la conversación no se debía al modelo de transcripción, que, de hecho, era muy preciso, sino que se basaba en el modelo de síntesis.

Otra ventaja de este diseño es que los costos son transparentes y fáciles de proyectar. Por ejemplo, el modelo de transcripción cuesta 1 USD por hora de audio, mientras que el modelo de síntesis de voz tiene un precio de 15 USD por millón de caracteres sintetizados. En una conversación estándar de una hora entre dos personas, podemos calcular directamente los costos de estos bloques específicos:

• Entrada de audio (transcripción): 1 hora = 1 USD
• Salida de audio (síntesis): 1 hora ≈ 0,15 USD

El salto a enero de 2026

Avanzando rápidamente hasta enero de 2026, nos encontramos con otro cliente con un caso de uso similar: un agente conversacional diseñado para entrevistar a los clientes por teléfono y recopilar sus datos para luego completar una declaración jurada. Esta vez, nos enfrentamos a un desafío adicional: el agente necesitaba una herramienta para actualizar de forma dinámica el registro de un cliente a medida que avanzaba la conversación. Esto requería un tiempo de procesamiento adicional entre las interacciones, lo que, naturalmente, amenazaba con aumentar la latencia. Decidimos dar otra oportunidad a los agentes de voz en tiempo real de Azure y, para nuestra sorpresa, la mejora en la experiencia del usuario fue notable.

La velocidad de respuesta del agente garantizó una interacción fluida, incluso cuando la herramienta estaba ocupada actualizando los registros de datos. Además, el modelo de síntesis ofrecía un tono mucho más natural, sin interrupciones en el diálogo del agente.

En tan solo unos meses, la API Voice-Live de Azure había conseguido mejorar considerablemente los resultados que podíamos conseguir, manteniendo su característica sencillez de implementación. Como podemos ver en el siguiente diagrama, la solución completa seguía siendo un componente único.

Sin embargo, esta simplicidad se consigue a costa de la visibilidad. Esto hace que la depuración de errores u optimización de partes específicas de la canalización sea engorrosa, si no imposible. Por ejemplo, la API Voice Live ofrece una selección limitada de modelos de transcripción, lo que se convierte en un obstáculo importante cuando se trata de acentos poco comunes o modismos locales.

Otra desventaja importante es que los costos de uso son mucho menos transparentes, lo que dificulta proyectar el costo de escalar a la producción. A diferencia de los modelos de transcripción o síntesis independientes, el precio de la API Voice Live se calcula por millón de tokens, pero no especifica el desglose entre los datos de entrada, los datos de salida o los tokens de razonamiento del modelo. En esencia, calcular el coste real del producto sigue siendo una «zona gris» hasta que lleguemos a la fase de pruebas con un grupo reducido de usuarios. Como referencia, el coste total de 4 horas de prueba fue inferior a 5 USD. Si bien esto proporciona una base útil para calcular los costes, es importante recordar que los precios de PoC rara vez se traducen de forma lineal en la producción, ya que la escalabilidad y los casos extremos pueden cambiar rápidamente las cifras.

Este caso ilustra perfectamente una tensión recurrente a la que nos enfrentamos al diseñar una solución: la elección entre el rápido desarrollo de una «caja negra» integrada y el control granular de una canalización personalizada. Si bien la actualización de enero de 2026 demuestra que, con el tiempo, los servicios gestionados mejoran su calidad, también sirve como recordatorio de que, con frecuencia, avanzar más rápido implica sacrificar la capacidad de echar un vistazo de forma oculta. A medida que avanzamos, nuestro desafío ya no es solo desarrollar la tecnología, sino decidir estratégicamente cuánto control estamos dispuestos a intercambiar en aras de la simplicidad.

Caso práctico 3: Clasificación de imágenes

Contexto de febrero de 2025

La clasificación de imágenes es un problema clásico al que nos hemos enfrentado en numerosas ocasiones en el laboratorio, y tradicionalmente lo hemos abordado ajustando los modelos de visión. Una de nuestras historias de éxito fue la de una empresa uruguaya dedicada a supervisar y promover la industria cárnica del país. El objetivo final era desarrollar una solución para clasificar los cortes de carne como de «buena calidad» o «de mala calidad». La empresa proporcionó un conjunto de datos de aproximadamente 2500 imágenes de matambre cortes (carne de rosas) con sus correspondientes etiquetas. Estas imágenes eran muy uniformes en términos de iluminación, fondo y calidad, pero un detalle importante era el importante desequilibrio de clases, ya que los cortes de «buena calidad» representaban solo alrededor del 25% del total de imágenes.

Con esto en mente, decidimos ajustar un modelo YOLO11, que naturalmente requería un esfuerzo centrado en el preprocesamiento de imágenes para manejar la baja variabilidad del conjunto de datos y el desequilibrio de clases. También implicaba un coste asociado a la potencia informática necesaria para entrenar el modelo, que en este caso era una máquina virtual de Azure equipada con una GPU. En la siguiente figura, presentamos el diagrama de esta solución.

En general, el proceso desde el trabajo inicial con los datos hasta la implementación de un modelo entrenado llevó una semana y obtuvimos resultados muy satisfactorios, con una precisión del 95%.

El salto a octubre de 2025

Varios meses después, nos encontramos con el caso de otra empresa uruguaya, esta vez especializada en el mantenimiento de sistemas de extinción de incendios para cocinas profesionales. Una parte clave de su proceso de mantenimiento consistía en que los técnicos tomaran fotografías de tres componentes específicos: el nivel de un agente líquido verde en el interior del tanque, la posición del manómetro y el peso del tanque medido en una báscula analógica. Estas fotos sirvieron como registro oficial para determinar si una cocina estaba lista para funcionar.

Para el primer componente, el nivel del líquido, el criterio era simple: el sistema estaba «en forma» si el líquido verde era visible a través de la ventana de inspección del tanque. Para el segundo, la posición de la aguja del medidor indicaba si el sistema de extinción de incendios estaba activado (lo que lo convertía en «no apto»). Por último, para el tercer componente, el peso mostrado en la báscula analógica tenía que estar dentro de un rango numérico específico.

El cliente se acercó al laboratorio con el objetivo de desarrollar un modelo de clasificación para cada uno de estos tres componentes. Proporcionaron un conjunto de datos de más de dos mil imágenes por caso, pero había un inconveniente: estaban completamente sin etiquetar. Además, dado que las fotografías fueron tomadas por técnicos con teléfonos móviles dentro de varias cocinas, las imágenes presentaban una gran variabilidad en la iluminación, la posición de los objetos y la calidad general.

Estas condiciones nos llevaron a la pregunta: ¿Entrenar a un modelo de visión es la mejor opción para este caso? En su lugar, decidimos probar la inferencia con uno de los modelos multimodales que ofrece Azure. Empezamos con la entonces flamante GPT 5.1 para clasificar el nivel de líquido, asumiendo que sería una tarea sencilla. Etiquetamos manualmente un pequeño conjunto de pruebas compuesto por 10 imágenes diferentes y, como era de esperar, no supuso ningún desafío para el modelo, ya logramos una precisión del 100%. Repetimos el proceso con 10 fotos de los medidores y, con una indicación bien elaborada, volvimos a alcanzar el 100% de precisión. Y lo mejor de todo es que esta PoC se desarrolló en una sesión de dos horas. Este es un diagrama de la solución final.

La historia era muy diferente con la escala. A pesar de que una persona podía leer fácilmente las mediciones con gran precisión, el modelo no podía proporcionar la precisión que el problema requería. Esta es una limitación bien documentada de los modelos multimodales, que se debe principalmente a las restricciones de resolución espacial provocadas por la tokenización de las imágenes. Por muy refinado que fuera el mensaje, este problema específico no se podía resolver con la misma sencillez que los dos anteriores.

Este caso nos llevó a ver un problema clásico y generalmente «resuelto» desde una nueva perspectiva. Si bien la clasificación de imágenes mediante un modelo multimodal conlleva un costo por inferencia que puede superar al de un modelo personalizado y ajustado, reduce significativamente el tiempo y el esfuerzo dedicados a la preparación, el etiquetado y el entrenamiento de los datos, y resuelve el problema de generalización que solemos tener cuando entrenamos modelos de visión con una variación baja en las muestras.

Sin embargo, los modelos multimodales no son una «fórmula mágica» para todos los casos de uso, al menos no todavía. La disyuntiva entre velocidad de despliegue y el precisión de modelos especializados sigue siendo un punto de decisión crucial. En escenarios con una alta precisión espacial, el enfoque tradicional de construir un canal de visión dedicado sigue siendo válido.

La compensación de opacidad

Hay un patrón en los tres casos. Cada vez que avanzábamos hacia una solución integral e integrada, ganábamos velocidad y perdíamos visibilidad. Vale la pena analizar esa desventaja en sus propios términos, porque afecta no solo a la forma en que construimos, sino también a la forma en que depuramos, auditamos y mantenemos.

En una tubería modular, la falla es aislable. Cuando el agente de voz integrado en STT → LLM → TTS producía una latencia alta, podíamos rastrear el cuello de botella hasta un bloque específico. Cuando el proceso de contraste de documentos no detectaba ninguna discrepancia, podíamos inspeccionar el texto extraído, los fragmentos recuperados y el resultado de la comparación del modelo como artefactos independientes. La arquitectura en sí misma posibilita el diagnóstico.

Las soluciones integradas colapsan esa estructura. Con la API Voice Live, una respuesta deficiente puede deberse a la calidad de la transcripción, el razonamiento, la síntesis o las condiciones de la red, y la superficie de la API no permite distinguirlas. Al aplicar la comprensión del contenido al contraste de documentos, si se pasa por alto una discrepancia, se plantea la misma cuestión sin resolver: ¿se trató de la extracción, la recuperación o del paso de comparación del modelo?

Este no es un argumento en contra de las soluciones integradas. El caso de los agentes de voz de enero de 2026 demostró que los servicios gestionados pueden alcanzar la calidad de la producción con una sencillez genuina. El caso de contraste de documentos con Content Understanding se creó en cuestión de horas en lugar de días, incluso en versión preliminar. A medida que estas herramientas sigan mejorando, la decisión rara vez girará en torno a la capacidad. Se basará en si la opacidad que viene acompañada de la simplicidad es aceptable para ese problema específico.

Nuestra opinión

El mayor cambio en la forma en que trabajamos no está en las herramientas. Está en las preguntas que hacemos antes de elegir una.

Un nuevo modelo o integración no es intrínsecamente mejor porque sea la versión más reciente. La arquitectura correcta depende del problema: cuánto cuesta una falla, cuánta visibilidad requiere la producción, qué tan rápido debe lanzarse la solución y si la versión simplificada ha madurado lo suficiente como para ser confiable.

Lo que comparten estos tres casos es que ninguno de ellos tenía una respuesta permanente. La cartera de documentos farmacéuticos siguió siendo modular porque la precisión no era negociable. El agente de voz optó por una solución integrada porque la calidad realmente había mejorado. El clasificador de imágenes terminó dividiendo el problema en dos, con diferentes enfoques para los diferentes componentes.

Como resultado, nuestro papel ha cambiado. Ya no nos dedicamos principalmente a desarrollar soluciones analíticas. Dedicamos más tiempo al modelado de soluciones y al pensamiento crítico que a escribir código. La pregunta central ya no es «¿cómo construimos esto?» sino «¿qué es lo que realmente necesita este problema y qué hay disponible hoy para solucionarlo?»

Ese cambio de pensamiento también cambia la forma en que diseñamos. En un entorno en el que puede aparecer un nuevo modelo o integración relevante cada pocos meses, el objetivo no es construir la solución más sofisticada, sino la más reemplazable. Esto significa definir límites claros entre los componentes, mantener la lógica empresarial desvinculada de modelos o proveedores específicos y tratar las solicitudes y configuraciones como artefactos versionados en lugar de cadenas incrustadas. No porque esperemos reconstruir constantemente, sino porque el costo del cambio debe ser una elección deliberada, no un accidente de la forma en que algo se conectó.

La decisión entre modular e integrado no se toma una vez al inicio de un proyecto. Se revisa a medida que las herramientas maduran, la calidad se pone al día y el costo de la opacidad se hace más evidente. No hay una respuesta permanente. Diseñe para la solución que necesita ahora, con la suficiente claridad en su estructura para que pueda reemplazar cualquier parte de la misma cuando llegue algo mejor. Lo hará.

‍

Si desea explorar las herramientas y los enfoques que analizamos, estos son buenos puntos de partida:

• API Voice Live para agentes de voz en tiempo real
• Clasificación de imágenes en Azure
• Creación de proyectos personalizados de Document Intelligence Studio