Ejecutar un LLM on-premise es solo el primer paso.
Si el objetivo es el análisis de hojas de cálculo con IA, el endpoint del modelo no es suficiente. Un usuario de negocio no quiere enviar JSON puro a un servidor de inferencia interno. Lo que busca es cargar un libro de trabajo, hacer una pregunta, obtener una respuesta fiable, generar un gráfico y saber de dónde provienen los números.
Esto requiere una arquitectura que rodee al modelo.
Esta guía explica los componentes principales de un sistema de hojas de cálculo con IA on-premise.
Arquitectura de referencia
Una arquitectura práctica de hojas de cálculo con IA on-premise tiene este aspecto:
El orden puede variar, pero el principio es constante: el LLM debe razonar y explicar, mientras que los sistemas controlados gestionan el acceso a los datos, el cómputo, la seguridad y la auditabilidad.
Identidad y control de acceso
Empiece por la identidad.
Cada respuesta de la IA debe estar vinculada a un usuario, un espacio de trabajo, un archivo y una decisión de permiso.
Los despliegues empresariales suelen requerir:
- SSO a través de SAML o OIDC
- Control de acceso basado en roles (RBAC)
- Mapeo de grupos desde el proveedor de identidad
- Permisos a nivel de espacio de trabajo
- Permisos a nivel de archivo
- Listas de permitidos para conjuntos de datos
- Controles de administración
Si el sistema se conecta a bases de datos o almacenamiento de objetos, no debe saltarse los permisos existentes. La IA no debe convertirse en un atajo para eludir la gobernanza.
Ingesta de libros de trabajo
La ingesta de hojas de cálculo es más difícil de lo que parece.
Un libro de trabajo real puede contener:
- Múltiples hojas
- Hojas ocultas
- Fórmulas
- Celdas combinadas
- Encabezados inconsistentes
- Rangos con nombre
- Comentarios
- Formato con significado implícito
- Hojas protegidas
- Gráficos y tablas dinámicas
- Enlaces externos
- Macros
Un sistema de producción debe analizar suficiente estructura para evitar dar al modelo una visión distorsionada de los datos.
Por seguridad, los archivos con macros habilitadas deben manejarse con cuidado. Si el sistema ejecuta algo, debe hacerlo en un sandbox. En muchos despliegues, las macros deben ser escaneadas, bloqueadas o tratadas como metadatos en lugar de ser ejecutadas.
Comprensión de la hoja de cálculo
Tras la ingesta, el sistema debe construir una representación útil del libro de trabajo.
Esto puede incluir:
- Resúmenes de hojas
- Límites de tablas
- Nombres de columnas y tipos inferidos
- Filas de muestra
- Mapas de dependencia de fórmulas
- Métricas detectadas
- Rangos de fechas
- Valores faltantes
- Anomalías
- Relaciones entre hojas o archivos
Esta representación es lo que el modelo debe ver primero. Enviar un libro de trabajo completo en un prompt suele ser ineficiente y arriesgado.
El objetivo es dar al modelo suficiente contexto para planificar el siguiente paso, no hacer que el modelo memorice todo el archivo.
Capa de cómputo determinista
Para la IA aplicada a hojas de cálculo, este es uno de los componentes más importantes.
El modelo no debe calcular números críticos internamente. Debe llamar a herramientas.
La capa de cómputo puede incluir:
- Fórmulas de hojas de cálculo
- SQL
- DuckDB
- pandas
- Polars
- Pushdown al almacén de datos
- Generación de gráficos
- Verificaciones de validación
Por ejemplo, si un usuario pregunta por los principales clientes por ingresos, el modelo puede identificar los campos correctos y producir una consulta. La capa de cómputo ejecuta la consulta. El modelo luego explica el resultado.
Esta separación mejora la precisión, la velocidad y la auditabilidad.
Servicio de modelos privados
La capa del modelo puede servirse de varias maneras.
vLLM se utiliza comúnmente para inferencia autohospedada de alto rendimiento y proporciona un servidor compatible con OpenAI.
KServe es útil cuando la organización busca un servicio de modelos nativo de Kubernetes y servicios de inferencia estándar.
NVIDIA NIM ofrece microservicios de inferencia optimizados para infraestructura acelerada por NVIDIA.
Ollama es útil para pilotos y pruebas locales, aunque los despliegues en producción suelen requerir un escalado, control de acceso y observabilidad más robustos.
La capa del modelo debe tratarse como infraestructura interna:
- Autenticada
- Con control de versiones
- Monitoreada
- Aislada por controles de red
- Configurada con políticas claras de retención de datos
- Evaluada antes de las actualizaciones del modelo
Orquestación de IA
La capa de orquestación decide cómo el sistema utiliza el modelo y las herramientas.
Se encarga de:
- Plantillas de prompts
- Selección del modelo
- Selección de herramientas
- Construcción del contexto
- Preguntas de aclaración
- Validación de consultas
- Sandboxing de código
- Lógica de reintentos
- Formateo de respuestas
En esta capa es donde residen muchos controles de seguridad.
Por ejemplo, si el modelo genera SQL, el sistema debe validar que el SQL sea de solo lectura, limitado a las tablas permitidas y que no sea demasiado costoso. Si el modelo genera Python, el sistema debe ejecutarlo en un sandbox con el acceso a la red deshabilitado a menos que se permita explícitamente.
Auditabilidad
Los registros de auditoría no son opcionales en despliegues serios.
Un registro útil debe incluir:
- Usuario
- Marca de tiempo
- Libro de trabajo o conjunto de datos accedido
- Prompt
- Nombre y versión del modelo
- Consulta, fórmula o código generado
- Resultados de las herramientas
- Respuesta final
- Decisiones de permisos
- Errores y alternativas (fallbacks)
Esto no significa que cada valor sensible deba almacenarse para siempre. La retención debe ser configurable. Pero el sistema necesita suficiente trazabilidad para revisión, depuración y cumplimiento normativo.
Observabilidad
Los equipos técnicos necesitan monitorear tanto la infraestructura como la calidad de las respuestas.
Métricas de infraestructura:
- Latencia
- Utilización de GPU
- Profundidad de la cola
- Uso de tokens
- Errores del modelo
- Tiempo de ejecución de herramientas
- Uso de almacenamiento
Métricas de calidad:
- Corrección de las respuestas
- Calidad de las citas
- Validez de las fórmulas
- Tasa de éxito de las consultas
- Correcciones del usuario
- Reportes de alucinaciones
- Aclaraciones fallidas
Sin observabilidad, los equipos no pueden saber si el analista de IA está mejorando o produciendo silenciosamente un trabajo poco fiable.
Errores comunes
Tratar al modelo como el motor de la hoja de cálculo
Esto conduce a totales alucinados y respuestas frágiles. Use herramientas para los cálculos.
Recuperar primero y filtrar después
Los permisos deben aplicarse antes de que el contexto llegue al modelo.
Ignorar la complejidad del libro de trabajo
Las demostraciones con archivos CSV no prueban que el sistema pueda manejar archivos de Excel reales.
Registrar demasiados datos sensibles
La auditabilidad es importante, pero los registros también deben seguir las reglas de retención y privacidad.
Construir alrededor de un solo modelo
Los modelos cambian rápidamente. Diseñe el flujo de trabajo de modo que el modelo pueda ser sustituido.
Un plan de despliegue por fases
Un despliegue realista puede realizarse por etapas.
- Prototipo con hojas de cálculo de muestra o anonimizadas.
- Validar tareas de análisis comunes y casos de fallo.
- Añadir cómputo determinista para todo el trabajo numérico.
- Conectar identidad y permisos antes de usar archivos reales.
- Desplegar un endpoint de modelo privado a través de vLLM, KServe, NIM u otro stack aprobado.
- Añadir registros de auditoría y monitoreo.
- Piloto con un equipo, generalmente finanzas, operaciones o reportes de ventas.
- Evaluar los resultados frente a respuestas conocidas antes de expandir.
Esto evita el error común de convertir una demo de un modelo en un sistema de producción antes de que exista la capa de gobernanza.
Dónde encaja RowSpeak
RowSpeak puede actuar como la capa de flujo de trabajo sobre los endpoints de modelos privados y la ejecución de datos gobernada.
El servidor del modelo proporciona el razonamiento. RowSpeak proporciona la experiencia de hoja de cálculo: carga de libros, preguntas en lenguaje natural, gráficos, resúmenes, informes y flujos de análisis orientados al usuario, como el informe de ventas semanal.
Para despliegues on-premise, esa separación es valiosa. El departamento de TI puede controlar el modelo y la infraestructura. Los usuarios de negocio pueden seguir trabajando a través de una interfaz diseñada para el análisis de hojas de cálculo en lugar de llamadas a APIs puras, ya sea que el resultado final sea un dashboard de IA o un informe financiero.
Reflexión final
Un endpoint de LLM on-premise es infraestructura. Un analista de hojas de cálculo con IA on-premise es una experiencia de producto más gobernanza.
El modelo es importante, pero la arquitectura que lo rodea determina si el sistema es confiable. Para un ejemplo específico de modelo, consulte la guía relacionada sobre cómo autohospedar DeepSeek para RowSpeak.
Fuentes y lecturas adicionales
- Servidor vLLM compatible con OpenAI: https://docs.vllm.ai/en/latest/serving/openai_compatible_server/
- KServe: https://kserve.github.io/website/
- NVIDIA NIM: https://www.nvidia.com/en-us/ai-data-science/products/nim-microservices/
- Biblioteca Ollama: https://ollama.com/library
- llama.cpp: https://github.com/ggml-org/llama.cpp
