Las 7 capas para implementar IA empresarial: de la GPU a la voz | SUMāTO

Cuando una empresa dice "queremos implementar inteligencia artificial", casi siempre está imaginando la última capa: un asistente que responde por texto o por voz. Lo que no se ve es que ese asistente es la punta de un stack de siete capas, y que el 80% del costo, del riesgo y del tiempo de implementación vive en las seis capas de abajo.

En SUMāTO llevamos 9 años integrando tecnología en Latinoamérica, y el patrón se repite: los proyectos de IA no fracasan en el modelo — fracasan en la infraestructura, en los datos o en la integración. Por eso hacemos aquí el ejercicio completo de arquitectura: si hoy tuviéramos que construir un asistente de IA empresarial con voz desde cero, ¿qué capas necesitaríamos, cómo funciona cada una por dentro, y qué servicios oficiales de qué fabricantes usaríamos?

Este es el mapa. Cada capa incluye su definición técnica, sus componentes internos, las métricas con las que se mide y las referencias a la documentación oficial de los fabricantes.

El stack completo, de abajo hacia arriba

Capa 7 — Presentación      TTS, canales de voz y texto
Capa 6 — Interacción       STT/ASR, endpointing, VAD
Capa 5 — Orquestación      Agentes, RAG, function calling, guardrails
Capa 4 — Modelo            LLM: inferencia, contexto, fine-tuning
Capa 3 — Datos             Ingesta, chunking, embeddings, BD vectorial
Capa 2 — Plataforma        Kubernetes, APIs, LLMOps, observabilidad
Capa 1 — Infraestructura   GPU, red, almacenamiento
─────────────────────────────────────────────────────
Transversal                Seguridad, gobierno, cumplimiento

Cada capa resuelve un problema distinto, se contrata con proveedores distintos, se mide con métricas distintas y falla de formas distintas. Vamos una por una.

Capa 1 — Infraestructura: dónde vive todo

Definición. Es la base de cómputo, red y almacenamiento sobre la que corre el resto del stack. La diferencia con la infraestructura de TI tradicional es una sola palabra: cómputo acelerado. Un LLM en inferencia ejecuta miles de millones de multiplicaciones de matrices por cada token generado; esa carga de trabajo es masivamente paralela y las CPUs convencionales no la sirven a latencia útil. Por eso el hardware de referencia son GPUs de centro de datos (NVIDIA H100/H200/B200 y familia Blackwell) o aceleradores propietarios de nube (AWS Trainium/Inferentia, Google TPU).

Conceptos técnicos que definen esta capa:

• Entrenamiento vs. inferencia. Entrenar un modelo fundacional requiere clústeres de miles de GPUs durante semanas — es territorio de los laboratorios de IA, no de la empresa. La empresa consume inferencia: servir un modelo ya entrenado. Toda la arquitectura empresarial se diseña para inferencia.
• Memoria de GPU (VRAM) como restricción dominante. Un modelo de 70 mil millones de parámetros en precisión FP16 necesita ~140 GB solo para cargar los pesos, más la memoria del KV-cache que crece con el largo del contexto. Esto determina cuántas GPUs necesitas y explica técnicas como la cuantización (reducir pesos a 8 o 4 bits, INT8/FP8/INT4) que recortan memoria y costo con pérdida mínima de calidad.
• Latencia de red. En un asistente de voz, el presupuesto total de latencia por turno es de ~800 ms para que la conversación se sienta natural. Cada tramo de red entre el canal telefónico, el motor STT, el LLM y el TTS consume parte de ese presupuesto; por eso la región de nube se elige por cercanía al usuario, no por precio.
• Almacenamiento de objetos (S3, Azure Blob) para datos crudos, artefactos y pesos de modelos, que pesan de decenas a cientos de GB por versión.

Servicios oficiales que usaríamos:

La decisión de consultoría: casi ninguna empresa en LATAM debería comprar GPUs propias para empezar. El modelo correcto es consumir inferencia como servicio (capa 4) y reservar infraestructura dedicada solo cuando el volumen lo justifique — típicamente arriba de varios millones de interacciones mensuales, o cuando la regulación exija que los datos no salgan de un perímetro definido.

Capa 2 — Plataforma: el sistema operativo del proyecto

Definición. Es la capa de ingeniería que convierte infraestructura cruda en un entorno operable y auditable: contenedores, APIs, pipelines de despliegue y la disciplina de LLMOps — la extensión de MLOps a modelos de lenguaje, donde el artefacto a versionar ya no es solo el modelo sino también los prompts, las configuraciones de RAG y los conjuntos de evaluación.

Componentes internos:

• Orquestación de contenedores. Kubernetes es el estándar de facto; en nube se consume gestionado como Amazon EKS o Azure AKS. Los microservicios del asistente (gateway, orquestador, conectores, evaluadores) se despliegan, escalan y actualizan aquí.
• Servidor de inferencia. Si el modelo es autoalojado, no se sirve "a mano": se usa un motor optimizado como vLLM, NVIDIA Triton Inference Server o TensorRT-LLM, que implementan técnicas como continuous batching y paged attention para multiplicar el throughput por GPU entre 5x y 20x frente a una implementación ingenua.
• API Gateway y gestión de tráfico. Punto único de entrada que autentica, aplica límites de tasa (rate limiting), enruta entre versiones de modelo y permite despliegues canario: enviar el 5% del tráfico a la versión nueva antes de promoverla.
• Observabilidad clásica + observabilidad de LLM. A los tres pilares tradicionales (logs, métricas, trazas) se agrega la traza semántica: qué prompt entró, qué contexto recuperó el RAG, qué respondió el modelo, cuánto costó en tokens y qué calificación obtuvo. Herramientas de referencia: LangSmith, MLflow, Arize Phoenix.
• Evaluación continua (evals). Baterías de casos de prueba que se ejecutan en cada cambio de prompt o de modelo, con jueces automáticos (LLM-as-judge) y muestreo humano. Sin esto, cada "mejora" es una apuesta.

Servicios oficiales que usaríamos: Amazon SageMaker AI o Azure Machine Learning para el ciclo de vida completo; Datadog o Grafana para observabilidad de plataforma.

La decisión de consultoría: esta capa es invisible para el negocio y por eso se subestima. Sin LLMOps, no hay forma de responder con datos la pregunta que el comité de dirección hará al mes tres: "¿el asistente está respondiendo bien, y mejor que el mes pasado?"

Capa 3 — Datos: la materia prima del conocimiento

Definición. Es la capa que convierte el conocimiento de la empresa (documentos, políticas, catálogos, historiales de sistemas) en un formato consultable por el modelo. El mecanismo central es el embedding: una función que transforma texto en un vector de cientos o miles de dimensiones (típicamente 384 a 3,072) cuya posición en el espacio captura el significado. Dos textos que dicen lo mismo con palabras distintas quedan cerca; la búsqueda deja de ser por palabras clave y pasa a ser búsqueda semántica.

El pipeline completo, paso a paso:

1. Ingesta. Conectores a los sistemas fuente: ERP, CRM, SharePoint, repositorios documentales. Para documentos escaneados o PDFs complejos se usa extracción con OCR e inteligencia documental: Amazon Textract o Azure AI Document Intelligence.
2. Chunking (segmentación). Los documentos se parten en fragmentos de 200 a 1,000 tokens. La estrategia importa: segmentar por estructura semántica (secciones, párrafos con solape) recupera mejor que cortar por tamaño fijo. Es una de las decisiones de mayor impacto en la calidad final y una de las menos discutidas.
3. Generación de embeddings. Cada fragmento pasa por un modelo de embeddings — distinto del LLM conversacional. Opciones oficiales: Amazon Titan Text Embeddings en Bedrock, text-embedding-3 de OpenAI, Cohere Embed, con desempeño multilingüe fuerte para español.
4. Indexación en base vectorial. Los vectores se almacenan en un índice optimizado para búsqueda de vecinos aproximados (ANN, típicamente con el algoritmo HNSW), que responde en milisegundos sobre millones de vectores. Opciones: Pinecone, Amazon OpenSearch Service con k-NN, Azure AI Search, pgvector sobre PostgreSQL para volúmenes moderados.
5. Recuperación híbrida y reranking. Los sistemas de producción combinan búsqueda vectorial con búsqueda léxica tradicional (BM25) y aplican un reranker — un segundo modelo que reordena los 50 candidatos iniciales y entrega los 5 mejores al LLM. Cohere Rerank y los rerankers de Azure AI Search son las referencias gestionadas.
6. Sincronización. El pipeline se re-ejecuta cuando el conocimiento cambia. Un asistente con datos de hace seis meses es un pasivo, no un activo.

Métricas de esta capa: recall@k (¿el fragmento correcto está entre los k recuperados?), precisión de la recuperación, y frescura del índice.

La decisión de consultoría: aquí se define la calidad real del asistente. Un LLM de última generación con datos mal segmentados responde peor que un modelo promedio con un pipeline de recuperación bien afinado. Es la inversión de mayor retorno por peso invertido en todo el stack, y por eso una base de analítica de datos ordenada es el prerrequisito real de cualquier proyecto de IA.

Capa 4 — Modelo: el motor de lenguaje (LLM)

Definición. El LLM (Large Language Model) es un modelo de lenguaje basado en la arquitectura Transformer, preentrenado sobre billones de tokens de texto para una tarea aparentemente simple — predecir el siguiente token — de la que emergen capacidades de comprensión, razonamiento y generación. Tres conceptos definen su comportamiento en producción:

• Tokens. La unidad de procesamiento: fragmentos de ~4 caracteres en promedio. Todo se cobra, se mide y se limita en tokens. Una conversación típica de servicio al cliente consume entre 2,000 y 10,000 tokens por turno contando el contexto.
• Ventana de contexto. Cuánto texto puede "tener presente" el modelo en una petición — hoy entre 128 mil y más de un millón de tokens según el modelo. Define cuánto historial de conversación y cuánto conocimiento recuperado cabe en cada turno.
• Temperatura y muestreo. Parámetros que controlan el balance entre respuestas deterministas (para procesos regulados) y creativas.

Los tres mecanismos de adaptación al negocio, en orden creciente de costo:

1. Prompt engineering. Instrucciones de sistema, ejemplos y formato de salida en cada petición. Costo bajo, iteración en horas.
2. RAG (Retrieval-Augmented Generation). El modelo consulta la capa 3 antes de responder y genera con base en fragmentos citados del conocimiento de la empresa. Reduce las alucinaciones — respuestas plausibles pero falsas — porque ancla la generación en fuentes verificables, sin reentrenar nada.
3. Fine-tuning. Reentrenamiento parcial con datos propios (técnicas como LoRA ajustan una fracción mínima de los parámetros). Se justifica solo con tareas muy repetitivas, formato de salida estricto o vocabulario extremadamente especializado — y después de agotar 1 y 2.

Servicios oficiales que usaríamos:

El trade-off central: API gestionada = máxima calidad y cero operación, pagando por token y aceptando que los datos transitan por el proveedor (con los controles contractuales y técnicos que eso exige). Modelo abierto autoalojado = control y residencia total de datos, a cambio de operar las capas 1 y 2 completas. Las plataformas multi-modelo (Bedrock, Foundry) son el punto medio pragmático: un solo contrato, varios modelos, gobernanza centralizada.

La decisión de consultoría: la pregunta correcta no es "¿cuál es el mejor modelo?" sino "¿cuál es el mejor modelo para este caso de uso, a este costo por interacción, con estos requisitos de datos?". Por eso el diseño correcto es agnóstico al modelo: una capa de abstracción que permita cambiar de proveedor sin reescribir el sistema. Los precios y capacidades de los LLMs cambian cada trimestre; la arquitectura no debería.

Capa 5 — Orquestación: de modelo a agente

Definición. Un LLM solo genera texto. La capa de orquestación lo convierte en un agente: un sistema que razona en pasos, consulta fuentes, ejecuta acciones en sistemas externos y mantiene el hilo de una conversación de principio a fin. Es la capa donde la IA deja de responder y empieza a operar.

Componentes internos:

• Function calling / tool use. El mecanismo por el cual el modelo, en lugar de responder texto, emite una llamada estructurada a una función definida por el integrador — consultar un pedido en el ERP, agendar una cita, generar un ticket, ejecutar un pago. El modelo decide qué herramienta invocar y con qué parámetros; el orquestador la ejecuta y devuelve el resultado al modelo. Está documentado como capacidad nativa en Anthropic, OpenAI y Bedrock.
• Gestión de contexto y memoria. Qué sabe el agente de la conversación actual (memoria de corto plazo, dentro de la ventana de contexto) y del cliente a lo largo del tiempo (memoria de largo plazo, persistida y recuperada vía la capa 3).
• Flujos multi-paso y planificación. Descomponer "quiero cambiar mi plan y que la factura llegue al nuevo correo" en las cuatro operaciones que realmente implica, con manejo de errores y confirmaciones intermedias.
• Guardrails. Reglas declarativas que delimitan qué puede y qué no puede hacer o decir el agente: temas vedados, montos máximos, acciones que requieren confirmación humana, filtrado de datos sensibles. Implementaciones gestionadas: Amazon Bedrock Guardrails y Azure AI Content Safety.
• Human-in-the-loop. El diseño explícito de cuándo el agente escala a una persona — por confianza baja, por política o por solicitud del cliente. La autonomía sin escalamiento no es madurez: es riesgo.

Frameworks y servicios oficiales: LangChain / LangGraph como framework de orquestación de código abierto; Amazon Bedrock Agents y los servicios de agentes de Microsoft Foundry como opción gestionada; Model Context Protocol (MCP), el estándar abierto impulsado por Anthropic para conectar agentes con herramientas y fuentes de datos de forma interoperable.

Aquí aparece una decisión de arquitectura relevante: existen plataformas de agente cognitivo (AI Agent) empaquetadas que resuelven esta capa — y buena parte de las capas 3 y 4 — como producto, con el ciclo autónomo completo: automatizar, decidir, mejorar. Como integradores agnósticos, en SUMāTO evaluamos con cada cliente cuándo tiene sentido construir la orquestación a medida sobre frameworks abiertos y cuándo conviene implementar una plataforma que ya traiga ese ciclo listo para conectarse a la operación.

Capa 6 — Interacción: entender la voz humana (STT)

Definición. Cuando el canal es voz, antes del LLM hay un paso crítico: STT (Speech-to-Text), también llamado ASR (Automatic Speech Recognition) — la tecnología que convierte la señal de audio en texto. Los sistemas modernos son modelos neuronales end-to-end entrenados sobre cientos de miles de horas de audio, y su calidad se mide en WER (Word Error Rate): el porcentaje de palabras insertadas, borradas o sustituidas respecto a la transcripción correcta.

Componentes internos de un STT de producción:

• Reconocimiento en streaming. Transcribir mientras la persona habla, emitiendo hipótesis parciales que se corrigen sobre la marcha, con latencias de 100–300 ms por fragmento. Es requisito absoluto para conversación natural; la transcripción por lotes (batch) se reserva para grabaciones.
• VAD (Voice Activity Detection). Detectar cuándo hay voz humana en la señal y cuándo hay silencio o ruido, para no procesar (ni facturar) audio vacío.
• Endpointing / detección de fin de turno. Decidir cuándo la persona terminó de hablar — el problema más difícil de la voz conversacional. Un umbral corto interrumpe; uno largo genera silencios incómodos. Los sistemas más avanzados usan señales semánticas, no solo acústicas: modelos como Deepgram Flux integran la detección de turno en el propio modelo de reconocimiento, con soporte para español.
• Adaptación de vocabulario (keyword boosting). Elevar la probabilidad de nombres de productos, siglas internas y términos regionales que el modelo genérico no conoce.
• Diarización. Distinguir quién habla en audio con múltiples voces — relevante en llamadas grabadas y análisis de conversaciones.
• Manejo de audio telefónico. La telefonía entrega audio a 8 kHz (banda estrecha), con códecs con pérdida y ruido de línea: condiciones muy distintas al micrófono de un smartphone. El modelo STT debe estar evaluado específicamente en ese dominio.

Servicios oficiales que usaríamos:

La decisión de consultoría: el STT es donde los proyectos de voz en LATAM se caen en silencio. Un WER de 15% en el acento y el dominio del cliente significa que una de cada siete palabras llega corrupta al LLM — y ningún modelo, por bueno que sea, razona bien sobre una entrada corrupta. La regla de SUMāTO: el STT se elige con un benchmark propio sobre audio real de la operación del cliente (llamadas reales, acento real, ruido real), nunca con el WER del sitio del fabricante, que está medido en condiciones de laboratorio.

Capa 7 — Presentación: responder en texto y en voz (TTS)

Definición. Es la capa que el usuario finalmente percibe. En texto, es la entrega por el canal (web, WhatsApp, aplicación). En voz, es TTS (Text-to-Speech): la síntesis neuronal que convierte la respuesta del LLM en voz con prosodia, pausas y entonación naturales. Los modelos actuales generan la forma de onda directamente con arquitecturas neuronales generativas, y la diferencia con la "voz de robot" de hace una década es categórica.

Componentes internos y métricas:

• TTFB de audio (Time To First Byte). Cuánto tarda en empezar a sonar la respuesta. Con síntesis en streaming — generar y reproducir mientras el LLM sigue escribiendo — el objetivo de producción es < 300 ms. Modelos optimizados para tiempo real como ElevenLabs Flash v2.5 operan alrededor de 75 ms de latencia de modelo.
• Calidad percibida (MOS). Mean Opinion Score, la métrica estándar de naturalidad evaluada por oyentes humanos en escala 1–5. Los TTS neuronales líderes superan 4.5.
• Voz de marca. Selección de voz de catálogo, diseño de voz sintética o clonación de voz a partir de muestras — con el requisito no negociable del consentimiento documentado del locutor.
• Soporte de español regional. Entonación mexicana, colombiana, rioplatense: no es el mismo producto. Los modelos multilingües actuales manejan español con calidad alta, pero se valida con oídos locales.
• SSML y control de prosodia. Marcado estándar para controlar pausas, énfasis, números y deletreo — crítico para leer montos, folios y direcciones sin ambigüedad.
• Canales. Telefonía (SIP/PSTN), WhatsApp Business, web chat, aplicaciones móviles. Cada canal tiene su integración, sus formatos de audio y sus reglas de negocio.

Servicios oficiales que usaríamos:

Y aquí cierra el stack: la capa de canales — especialmente la telefónica — es lo que resuelve una plataforma de contact center omnicanal con IA: enrutamiento, telefonía, WhatsApp y la transferencia a agente humano cuando la conversación lo requiere. La arquitectura completa — un agente cognitivo como cerebro y una plataforma de canales como sistema de contacto — es el ejemplo concreto de cómo estas siete capas se materializan sobre la operación real del cliente.

El debate de arquitectura de 2026: pipeline en cascada vs. speech-to-speech nativo

Hasta aquí describimos la arquitectura en cascada: STT → LLM → TTS, tres modelos encadenados. Es la arquitectura dominante en producción porque cada eslabón se elige, se mide y se reemplaza por separado — el diseño agnóstico que recomendamos.

Pero existe una segunda arquitectura emergente: los modelos speech-to-speech nativos, que procesan audio de entrada y generan audio de salida directamente, sin pasar por texto intermedio. La Realtime API de OpenAI es la referencia comercial: modelos multimodales nativos que escuchan, razonan y hablan en una sola sesión por WebRTC o WebSocket, con detección de turno integrada y function calling durante la conversación. La promesa: menor latencia total y preservación de señales que el texto pierde — tono, emoción, titubeos.

Nuestra lectura de consultoría:

Para operaciones reguladas — banca, salud, seguros, gobierno — la cascada sigue siendo la recomendación por auditabilidad y control. El speech-to-speech nativo vale un piloto en casos de experiencia premium donde la latencia lo es todo. Es exactamente el tipo de decisión de arquitectura que evaluamos caso por caso.

Capa transversal — Seguridad, gobierno y cumplimiento

Ninguna de las siete capas anteriores va a producción sin esta. Definición: el conjunto de controles técnicos y organizacionales que garantizan que el asistente maneja datos personales conforme a la regulación aplicable (en México, la LFPDPPP; en la región, marcos equivalentes; para clientes con operación europea, el AI Act como referencia de clasificación de riesgo), que las conversaciones están cifradas y auditadas, y que existe trazabilidad de cada decisión automatizada.

Componentes mínimos:

• Cifrado en tránsito (TLS 1.2+) y en reposo, con gestión de llaves del cliente (AWS KMS, Azure Key Vault).
• IAM y mínimo privilegio: el agente accede solo a las funciones y datos que su rol exige — las credenciales del agente son un activo de seguridad de primera clase.
• Enmascaramiento de PII antes de que los datos lleguen al LLM cuando el caso de uso no los requiere, y políticas contractuales de no-retención y no-entrenamiento con los proveedores de modelo (Bedrock y Foundry documentan explícitamente sus compromisos de datos empresariales).
• Defensa contra amenazas propias de LLM: inyección de prompts, fuga de instrucciones de sistema, jailbreaks. La referencia pública es el OWASP Top 10 para aplicaciones LLM.
• Perímetro y red: firewalls de siguiente generación y segmentación — territorio Fortinet en nuestro ecosistema de ciberseguridad — más los controles nativos de nube (AWS GuardDuty, Microsoft Defender, Microsoft Purview para gobierno de datos).
• Gobierno de IA como práctica: registro de casos de uso, evaluación de riesgo por caso, comité de revisión y auditoría periódica de comportamiento del agente. El marco de referencia público es el NIST AI Risk Management Framework.

El resumen ejecutivo del stack

Conclusión: la tecnología es nueva, la disciplina para adoptarla no lo es

Todas las piezas de este stack existen como servicio, están documentadas públicamente por sus fabricantes y se contratan con tarjeta de crédito. Lo que no se contrata con tarjeta de crédito es el criterio para elegirlas, conectarlas y gobernarlas.

Y aquí conviene decir algo con franqueza: hoy hay una sobreoferta de "expertos en IA" sobre una tecnología en la que todos estamos aprendiendo — laboratorios, fabricantes, integradores y clientes por igual. Los modelos cambian cada trimestre, las mejores prácticas se están escribiendo en tiempo real, y buena parte de las arquitecturas que hoy se proponen nacen del ensayo y error. Eso no es un defecto del mercado: es la naturaleza de una tecnología en plena curva de maduración. El defecto está en disfrazar el experimento de certeza.

La buena noticia es que, desde la consultoría, el procedimiento para adoptar tecnología en un ambiente corporativo no ha cambiado en lo esencial en los últimos años — y es precisamente lo que protege a la empresa cuando la tecnología sí cambia cada trimestre:

1. Entendimiento del negocio antes que la tecnología. El proceso arranca en el problema, no en el modelo: qué proceso duele, cuánto cuesta ese dolor, qué resultado medible lo resolvería. Un caso de uso sin línea base cuantificada no es un caso de uso; es una demo esperando presupuesto.

2. Análisis riguroso del proveedor. Casos de éxito verificables — con clientes a los que se les puede llamar —, salud financiera del fabricante, roadmap público, documentación oficial (por eso este artículo la cita capa por capa) y modelo de soporte. Un proveedor que no puede mostrar referencias comparables a tu industria y tu escala todavía está experimentando; puede ser un socio válido para un piloto, no para el core de la operación.

3. Demos y pruebas de concepto con alcance controlado. Ver la tecnología funcionando sobre un escenario propio, con criterios de salida definidos antes de empezar: qué exactitud, qué latencia, qué costo por interacción convierten el piloto en proyecto — y qué resultados lo cancelan. Un piloto sin criterio de cancelación no es un piloto; es una compra disfrazada.

4. Validación de calidad antes de implementar. Benchmark con datos reales de la operación (el WER con el acento real, el recall con los documentos reales), pruebas de seguridad, validación de cumplimiento regulatorio y evaluación de la experiencia con usuarios reales. En IA esta etapa pesa más que nunca, porque los modelos son probabilísticos: no basta con que funcione en la demo; hay que medir con qué frecuencia y en qué condiciones deja de funcionar.

5. Implementación gradual con gobierno desde el día uno. Despliegue por fases, con humano en el circuito, métricas de operación y un comité que revisa el comportamiento del sistema — no al final del proyecto, sino durante toda su vida.

Y dos reglas que no admiten excepción, porque los errores en estos puntos no se corrigen con una nueva versión del modelo:

• Cuida los datos de tu empresa. Antes de conectar cualquier sistema de IA, la pregunta obligada es: ¿a dónde viajan mis datos, quién los retiene, se usan para entrenar modelos de terceros, y qué dice el contrato al respecto? Los proveedores serios documentan públicamente sus compromisos de no-retención y no-entrenamiento con datos empresariales; si un proveedor no puede responder esto por escrito, la conversación termina ahí. La información de la compañía — clientes, precios, contratos, operación — es un activo estratégico, no un dato de prueba.
• No te integres con soluciones caseras o implementaciones dudosas. Un wrapper armado en un fin de semana sobre la API de un modelo puede verse idéntico a una plataforma empresarial en una demo de 30 minutos. La diferencia aparece en producción: sin cifrado serio, sin auditoría, sin soporte, sin roadmap y — el riesgo mayor — con los datos de tu empresa fluyendo por infraestructura que nadie certificó. El costo de deshacer una mala integración siempre supera al de haberla evaluado bien.

Ese es el trabajo de un integrador agnóstico: aplicar una metodología probada a una tecnología que está madurando, sin conflicto de interés por vender una pieza en particular. En SUMāTO no fabricamos ninguna de estas piezas, y precisamente por eso podemos elegir la mejor para cada capa y cada cliente — la nube correcta, el modelo correcto, el STT que sí entiende el acento de tu operación, y la plataforma —sea a medida sobre frameworks abiertos o empaquetada— que convierte el stack en resultados operativos. Nuestro método — Consultoría → Diseño → Procesos → Gobierno — es exactamente la secuencia anterior, sistematizada.

¿Quiere adoptar IA con método y no con moda? El punto de partida es nuestro Diagnóstico 360°: en 90 días entendemos su negocio, mapeamos su arquitectura actual contra este stack, evaluamos proveedores con criterios objetivos y entregamos la ruta de implementación priorizada por valor y factibilidad — con los datos de su empresa protegidos en cada paso.

Agendar Diagnóstico 360°

Preguntas frecuentes

¿Cuántas capas tiene realmente un asistente de IA empresarial?
Siete capas funcionales más una transversal de seguridad y gobierno: infraestructura, plataforma, datos, modelo (LLM), orquestación, interacción (STT) y presentación (TTS). El asistente que el usuario percibe es solo la última; el 80% del costo, del riesgo y del tiempo de implementación vive en las capas inferiores.

¿Qué diferencia hay entre RAG y fine-tuning?
RAG hace que el modelo consulte el conocimiento de la empresa antes de responder, sin reentrenar nada, y reduce alucinaciones porque ancla la generación en fuentes citables. El fine-tuning reentrena parcialmente el modelo con datos propios y solo se justifica en tareas muy repetitivas, con formato de salida estricto o vocabulario muy especializado — después de agotar prompt engineering y RAG.

¿Conviene la arquitectura en cascada (STT→LLM→TTS) o speech-to-speech nativo?
Para operaciones reguladas —banca, salud, seguros, gobierno— la cascada sigue siendo la recomendación: cada componente se elige, se audita y se reemplaza por separado, y la transcripción textual sirve como evidencia. El speech-to-speech nativo ofrece menor latencia y vale un piloto en experiencias premium, pero implica más lock-in y una trazabilidad aún en construcción.

¿Cómo se elige el motor de STT para español en Latinoamérica?
Con un benchmark propio sobre audio real de la operación: llamadas reales, acento real, ruido real y audio telefónico a 8 kHz. Nunca con el WER publicado por el fabricante, medido en laboratorio. Un WER de 15% significa que una de cada siete palabras llega corrupta al LLM, y ningún modelo razona bien sobre una entrada corrupta.