“¿Podemos ejecutar esto en nuestra propia infraestructura, sin enviar datos a terceros?” es una pregunta que surge cada vez con más frecuencia en los proyectos en los que se utiliza un ERP. En la oficina tenemos un NVIDIA DGX Spark, así que he preparado una prueba concreta con cifras reales: ejecutar Gemma 4 de Google a nivel local, en comparación con la ejecución del mismo modelo en Amazon Bedrock.
Lo que no probé (a propósito)
Si la tarea consistiera en “extraer el proveedor, el número de factura, las partidas y los totales de un PDF con un diseño conocido”, no utilizaría ningún modelo de lenguaje. Utilizaría Textract, Azure AI Document Intelligence (antes Form Recognizer) o simples reglas de diseño: es más rápido, más barato, determinista y no depende de que un modelo “interprete” un valor que se encuentra en una posición fija del documento. Utilizar un modelo de lenguaje grande (LLM) para eso es como usar un martillo neumático para colgar un cuadro.
La tarea que merece la pena probar
Un modelo de lenguaje grande (LLM) empieza a demostrar su utilidad allí donde las herramientas de extracción clásicas se quedan cortas: cuando hay una nota de texto libre que hay que interpretar y no existe un campo específico para ello. Creé varias facturas sintéticas (con datos inventados), cada una con una línea de observaciones que describía un caso extremo diferente: una entrega parcial, datos de acceso que el mensajero necesita para la entrega, unidades aún pendientes de recepción; nada de ello en un campo estructurado.
Le pedí a Gemma 4 31B que devolviera un JSON con los campos de la factura, además de un campo de alertas para cualquier discrepancia que se encontrara en el texto libre. Se trata de una evaluación de contenido no estructurado, el tipo de tarea que hoy en día sigue realizando una persona al leer la factura completa durante una comprobación de coincidencia a tres bandas.
Ronda 1: local, en el Spark
He instalado Ollama, he descargado gemma4:31b (20 GB) y he ejecutado el prompt con la API local.
En todos los ejemplos extrajo todos los campos correctamente y, en las alertas, señaló aspectos como la entrega parcial y las unidades pendientes, extrayendo esta información del texto libre en lugar de un campo específico. Los resultados fueron correctos. El tiempo de respuesta, no tanto. En el caso de una factura representativa:
- Carga del modelo en la GPU (primera ejecución): unos 35 segundos
- Generación de respuestas: ~168 segundos, a ~10 fichas por segundo
- Total: ~3 minutos y 20 segundos por factura
Había un dato que no cuadraba: la respuesta visible es de unos 1.150 caracteres, pero el modelo generó unos 1.720 tokens para llegar a ella. Repetí la extracción con las demás facturas y también probé con una indicación de texto sin formato, sin JSON ni números, y en todos los casos la proporción entre tokens y caracteres siguió siendo extraña. La orden “ollama show” reveló la causa: gemma4:31b viene con la opción «thinking» activada por defecto. Genera un razonamiento interno antes de la respuesta (en una ejecución, incluso en inglés, a pesar de que la solicitud estaba en español), y ese razonamiento consume tiempo y tokens sin aparecer en el resultado final.
Repetí la extracción con «think: false»: los resultados fueron los mismos, incluidas las alertas, en aproximadamente 1 minuto en lugar de 3 minutos y 20 segundos. Aproximadamente 3,4 veces más rápido, a la misma velocidad de generación por token. Toda la diferencia radicaba en un razonamiento oculto que no aportaba nada a esta tarea concreta. Merece la pena probar esa opción antes de dar por definitiva la latencia predeterminada de un modelo.
Ronda 2: el mismo modelo, en Bedrock
Gemma 4 31B está disponible en Amazon Bedrock desde junio de 2026, en cuatro regiones, incluida Europa (Fráncfort). Esto permite realizar una comparación sin conjeturas sobre el cambio de tokenizador: el mismo modelo, dos formas de ejecutarlo. (En Bedrock, el modo de razonamiento está desactivado por defecto, lo que coincide con la ejecución «think: false» anterior.)
Bedrock cobra ~$0,12 / $0,35 por cada millón de tokens de entrada/salida para este modelo. Con las cifras reales de tokens que he calculado (883 de entrada y 621 de salida por factura), 100 facturas cuestan aproximadamente $0.03.
En una empresa, “ejecutarlo por cuenta propia” significa utilizar una instancia de GPU en la nube, no comprar un DGX Spark: por ejemplo, una g6.xlarge en AWS (GPU L4, 24 GB, suficiente para ejecutar este modelo), a un precio aproximado de $0,80 por hora. Procesar 100 facturas allí, incluso en el mejor de los casos (la GPU ocupada el 100% del tiempo sin segundos de inactividad, lo cual no es realista para lotes pequeños y esporádicos), cuesta aproximadamente $1.34 (unas 40 veces más caro que el mismo modelo en Bedrock).
La razón es sencilla: un proveedor de servicios en la nube reparte el coste de esa GPU entre miles de clientes. En cambio, si compras o alquilas tu propia instancia, se te facturará el importe íntegro aunque solo la utilices cinco minutos al día.
La letra pequeña de “los datos no salen de mi red”
Normalmente, aquí es donde se acaba la conversación (“Voy a ejecutar algo a nivel local y ya está”), y donde merece la pena analizarlo con más detalle. He comprobado dos cosas:
Bedrock no transfiere automáticamente tus datos fuera de la UE. La forma en que se canalizan los datos depende de cómo se invoque el modelo, y existen tres modos distintos:
- ID del modelo regional (dentro de la región): esta es la opción predeterminada. La solicitud nunca sale de la región desde la que realizas la llamada. No hay que configurar nada: a menos que elijas explícitamente otra opción, el procesamiento se realiza en tu región de origen.
- Perfil de inferencia geográfica de la UE (
eu.prefijo). Las solicitudes se pueden distribuir entre las distintas regiones de AWS, pero solo en la UE (Fráncfort, Irlanda, París). Los datos siguen sin salir de la UE. Esta es la opción recomendada por AWS para la residencia de datos en la UE y, en el caso de algunos modelos más recientes, es la única forma de ejecutarlos bajo demanda. - Perfil de inferencia global (
global.prefijo). Las solicitudes pueden redirigirse a regiones comerciales de AWS de todo el mundo, incluidos los EE. UU. Este es el único modo que realmente saca datos de la UE, y su uso requiere una aceptación explícita.
Por lo tanto, “interregional” no es sinónimo de “salir de la UE”.”: el perfil de la UE mantiene todo dentro de la UE, y solo el perfil global traspasa esa frontera. Hay dos salvedades que conviene tener en cuenta: cuando se utiliza un perfil interregional y el modelo está sujeto a la detección de abusos, AWS puede almacenar las entradas y los resultados en la región de destino (no solo transmitirlos en memoria); y AWS afirma que no almacena tus entradas y salidas, ni las utiliza para entrenar modelos, ni las comparte con proveedores de modelos externos, en ningún caso.
Un aspecto relacionado que a menudo se pasa por alto: una región de la UE de un proveedor con sede en EE. UU. resuelve geográfico residencia, pero los datos pueden seguir estando sujetos a la jurisdicción de EE. UU. (por ejemplo, la Ley CLOUD). Se trata de un aspecto distinto de “en qué país se encuentran los servidores”, y es parte del motivo por el que “sin terceros” y “en la UE” no son el mismo requisito. (Esto no constituye asesoramiento jurídico… consúltalo con tu equipo de cumplimiento normativo).
“Conforme al RGPD” y “los datos nunca pasan por infraestructuras de terceros” no son lo mismo. Bedrock en Fráncfort, si se configura correctamente, resuelve la cuestión de la residencia geográfica (los datos se procesan y almacenan en la UE), que es lo que exige el RGPD en la mayoría de los casos. Sin embargo, no resuelve otro requisito diferente y más estricto: que los datos nunca pasen por una infraestructura que no se controle, independientemente del país. Este segundo requisito aparece en contratos con cláusulas de “sin subencargados del tratamiento”, en algunos sectores regulados (defensa, determinados organismos públicos) o con clientes que, sencillamente, no confían en una nube de terceros más allá de lo que figura por escrito. Nada de esto constituye asesoramiento jurídico: cada caso debe validarse con el equipo de cumplimiento normativo pertinente, pero la distinción entre “en la UE” y “en mi propia infraestructura” es lo que, en la práctica, determina si Bedrock es suficiente.
Entonces, ¿en qué casos tiene sentido ejecutarlo localmente?
Teniendo en cuenta las cifras anteriores, casi nunca por motivos de coste: un modelo alojado en tu propia región, debidamente configurado, ya cumple la mayoría de los requisitos normativos reales por una fracción del precio. Los casos en los que sigue teniendo sentido ejecutarlo localmente (o en tu propia nube privada) son más limitados de lo que sugiere el discurso de los “modelos abiertos”:
- El requisito contractual o normativo es, literalmente, “sin terceros”,” no “en esta región”: defensa, determinados organismos públicos o cláusulas de prohibición de subcontratación que Bedrock no puede cumplir en ninguna configuración.
- El entorno carece de conectividad fiable o está aislado físicamente por diseño (plantas industriales, entornos de tecnología operativa, emplazamientos remotos).
- Ya gestionas la infraestructura de GPU por otro motivo (no lo compras solo por esto), por lo que el coste marginal de añadir esta carga de trabajo es bajo y la comparación anterior ya no es válida.
Aparte de esos casos, antes de justificar la adquisición de tu propio hardware, conviene comprobar si la necesidad real tiene que ver con la región o con terceros. Son cosas diferentes, y comprar una GPU solo resuelve la segunda.
Fuentes
- Inferencia geográfica entre regiones — Guía del usuario de Amazon Bedrock
- Inferencia global entre regiones — Guía del usuario de Amazon Bedrock
- Aumenta el rendimiento con la inferencia entre regiones — Guía del usuario de Amazon Bedrock
- Aprovechar la flexibilidad de la IA en Europa: guía sobre la inferencia interregional para el tratamiento de datos de la UE — Blog de AWS Machine Learning
- Protección de datos — Guía del usuario de Amazon Bedrock
- Cómo utiliza Amazon Bedrock los datos de entrada y salida de los modelos — AWS re:Post
