OpenAI API vs LLMs autohospedados para asistentes en la app

Lo que realmente estás decidiendo al añadir un asistente en la app

Un asistente en la app puede significar varias cosas. A veces es un ayudante de soporte que responde “¿Cómo restablezco mi contraseña?” Otras veces es una búsqueda que encuentra el registro, la política o la factura correcta. En otras ocasiones es un asistente de flujo de trabajo que realiza acciones, como “crear un ticket, asignarlo a María y notificar al cliente”. Son trabajos muy diferentes y traen riesgos distintos.

La elección entre OpenAI API vs LLMs autohospedados no se reduce solo a la calidad del modelo. Estás decidiendo qué puede ver tu asistente, qué tan rápido debe responder y quién es responsable cuando algo falla a las 2 a. m.

Una vez que los usuarios dependen del asistente a diario, los pequeños problemas se vuelven grandes. Si el asistente es lento, dejan de usarlo y vuelven al trabajo manual. Si da una respuesta errónea con confianza, las entradas de soporte aumentan. Si expone datos privados, tienes un incidente, no una característica.

“Producción” cambia las reglas. Necesitas un tiempo de actividad predecible, límites claros sobre qué datos se envían a un modelo y una forma de explicar el sistema a auditores o revisores de seguridad. También necesitas lo básico operativo: monitorización, alertas, rollbacks y una alternativa humana cuando el asistente no puede ayudar.

Dos enfoques comunes:

• Modelo hospedado por API: envías prompts al modelo hospedado por un proveedor y recibes respuestas. El proveedor gestiona la infraestructura y el escalado.
• Modelo open‑source autohospedado: ejecutas el modelo en tus propios servidores o cuenta cloud. Gestionas despliegue, rendimiento y actualizaciones.

Un ejemplo concreto: imagina un portal de clientes donde los usuarios preguntan “¿Por qué me negaron el reembolso?” Si el asistente sólo resume un artículo público de ayuda, las implicaciones de privacidad son bajas. Si lee notas internas, estado de pagos e historial de soporte, necesitas límites estrictos. Si además puede ejecutar acciones (reembolsar, restablecer contraseña, bloquear cuenta), necesitas permisos fuertes, registro de auditoría y una ruta clara de aprobaciones.

Herramientas como AppMaster pueden ayudarte a construir la aplicación alrededor del asistente, incluyendo autenticación, registros respaldados por base de datos y lógica de flujo de trabajo. La decisión central sigue siendo la misma: qué tipo de asistente estás construyendo y qué nivel de fiabilidad y control necesitas para operarlo con seguridad para usuarios reales.

Límites de privacidad: qué datos salen de tu sistema y cuándo

La privacidad no es un interruptor. Es un mapa de flujos de datos: qué envías al modelo, qué almacenas alrededor de cada petición y quién puede acceder a ello después.

Con un modelo API, lo obvio son los prompts. En la práctica, los prompts a menudo incluyen mucho más de lo que el usuario escribió: historial de chat, detalles de cuenta que inyectaste como contexto, fragmentos extraídos de documentos y resultados de herramientas (como “últimas facturas” o “tickets de soporte abiertos”). Si permites subir archivos, esos archivos también pueden formar parte de la petición. Por separado, tus propios logs, analíticas y trazas de error pueden capturar prompts y salidas a menos que evites explícitamente que lo hagan.

El auto‑hospedaje desplaza el límite. Los datos pueden quedarse dentro de tu red, lo que ayuda con cumplimiento estricto. Pero no los hace privados automáticamente. Aún debes controlar el acceso interno (ingenieros, soporte, contratistas), asegurar las copias de seguridad y decidir cuánto tiempo conservas conversaciones en bruto para depuración.

Antes de elegir una configuración, obtén respuestas claras a unas pocas preguntas:

• ¿Cuánto tiempo se retienen los datos de la petición?
• ¿Se usan para entrenamiento o evaluación?
• ¿Quién puede acceder a ellos en el lado del proveedor o dentro de tu empresa?
• ¿Qué pistas de auditoría y opciones de eliminación existen?

Si alguna respuesta es vaga, asume el caso más estricto y diseña en consecuencia.

Los campos sensibles necesitan manejo especial: nombres, correos, direcciones, historial de pedidos, políticas internas y todo lo relacionado con pagos. Un ejemplo simple: un cliente pregunta “¿Por qué me rechazaron la tarjeta?” Tu asistente puede explicar los siguientes pasos sin enviar nunca los datos completos de la tarjeta (que no deberías almacenar de todos modos) ni datos personales innecesarios al modelo.

Un conjunto práctico de reglas que funciona en API y en setups autohospedados:

• Envía el mínimo contexto necesario para responder la pregunta.
• Redacta o reemplaza identificadores (usa ID de usuario en lugar de email cuando sea posible).
• Mantén los prompts y salidas en bruto fuera de logs generales por defecto.
• Usa retenciones cortas para datos de depuración, con un camino claro de eliminación.
• Separa la “memoria” del asistente de los registros reales, de modo que un chat no pueda sobrescribir hechos.

Si construyes el asistente dentro de una plataforma como AppMaster, trata tu base de datos como fuente de la verdad. Ensambla prompts solo con los campos específicos que el asistente necesita, en vez de volcar registros enteros “por si acaso”.

Latencia y experiencia de usuario: dónde se va el tiempo

La latencia se siente diferente dentro de un producto que en una demo porque los usuarios ya están en flujo. Si una respuesta tarda 6 segundos, no es “solo esperar”. Es un paso roto entre pulsar un botón y terminar la tarea.

Con OpenAI API vs LLMs autohospedados, el tiempo de espera suele venir de lugares distintos. El intercambio no es solo la velocidad del modelo, sino todo lo que envuelve la llamada al modelo.

Los costes de tiempo ocultos

Para un modelo API, el tiempo se pierde a menudo en saltos de red y procesamiento fuera de tu control. Una sola petición puede incluir DNS, establecimiento de TLS, enrutamiento al proveedor, la ejecución del modelo y el viaje de vuelta.

En la inferencia autohospedada puedes eliminar la mayoría de saltos por internet, pero añades cuellos de botella locales. Contención de GPU, lecturas de disco y tokenización lenta pueden importar más de lo que esperas, especialmente si el servidor también ejecuta otras cargas.

El tráfico pico es donde la historia cambia. Las llamadas a la API pueden encolarse en el lado del proveedor, mientras que los sistemas autohospedados se encolan en tus propias GPUs. “Rápido en promedio” aún puede significar “picos molestos” cuando 50 usuarios preguntan a la vez.

Los arranques en frío también aparecen en producción. Pods que escalan automáticamente, gateways y pesos de modelo recién cargados pueden convertir una respuesta de 1 segundo en 15 segundos justo cuando un usuario necesita ayuda.

Tácticas de UX que protegen la experiencia

A menudo puedes hacer que el asistente parezca más rápido sin cambiar el modelo:

• Transmite tokens para que el usuario vea progreso en vez de una pantalla en blanco.
• Muestra un mensaje corto de “trabajando” y revela resultados parciales (como primeros pasos o un resumen).
• Define timeouts claros y usa una respuesta más simple como fallback (“Aquí están las 3 opciones más probables”).
• Cachea respuestas comunes y reutiliza embeddings para búsquedas repetidas.
• Mantén prompts pequeños enviando solo el contexto más relevante.

Ejemplo: en un portal de clientes construido en AppMaster, un asistente “¿Dónde está mi factura?” puede confirmar inmediatamente la cuenta y traer las últimas 5 facturas desde tu base de datos. Aunque el LLM tarde más, el usuario ya ve datos útiles y el mensaje final del asistente se siente como ayuda, no como demora.

Previsibilidad de costes: lo que puedes pronosticar y lo que no

El coste no es solo “cuánto por mensaje”. Es con qué frecuencia la gente usa el asistente, cuánto dura cada prompt y qué se le permite hacer al asistente. En la decisión OpenAI API vs LLMs autohospedados, la diferencia principal es si tu coste se comporta como un contador (API) o como planificación de capacidad (auto‑hospedaje).

Con una API, el precio suele escalar con unos pocos factores: tokens de entrada y salida (tu prompt, la respuesta del modelo y cualquier instrucción del sistema), el nivel de modelo que escoges y trabajo extra de herramientas (por ejemplo, llamadas a funciones, recuperación o lógica multi‑paso que aumenta el uso de tokens). Esto funciona bien para pilotos porque puedes empezar pequeño, medir y ajustar. Se complica cuando el uso se dispara, porque la factura puede dispararse también.

La auto‑instalación puede parecer más barata por mensaje, pero no es gratis. Pagas por GPUs (a menudo ociosas si sobredimensionas), almacenamiento, redes, monitorización y la gente que lo mantiene. El mayor coste oculto es el riesgo: un día con mucho tráfico, un fallo de modelo o un despliegue problemático puede traducirse en tiempo de inactividad y pérdida de confianza.

Lo que hace que los costes sean difíciles de predecir en ambos setups es el comportamiento que no controlas bien al principio: prompts largos (historial de chat y grandes trozos de conocimiento), reintentos tras timeouts y el mal uso. Un solo usuario puede pegar un documento enorme, o un bucle en tu lógica puede llamar al modelo varias veces. Si tu asistente puede ejecutar acciones, las llamadas a herramientas se multiplican rápido.

Formas de limitar el gasto sin arruinar la experiencia:

• Establece presupuestos diarios y mensuales con alertas y decide qué sucede al alcanzarlos.
• Añade límites de tasa por usuario y por espacio de trabajo, especialmente en niveles gratuitos.
• Pon límites estrictos en la longitud de respuesta (max tokens) y en el tamaño del historial de chat.
• Cachea respuestas comunes y resume el contexto antiguo para reducir tokens.
• Bloquea entradas enormes y reintentos repetidos.

Ejemplo: un asistente de portal de clientes construido en AppMaster puede empezar con preguntas cortas de “cuentas y facturación”. Si luego permites buscar tickets, resumir hilos largos y redactar respuestas, el uso de tokens puede saltar de la noche a la mañana. Planifica límites temprano para que el crecimiento no sorprenda a finanzas.

Si quieres probar supuestos de precio rápido, construye un piloto pequeño, registra tokens por tarea y aprieta límites antes de abrirlo a todos.

Carga operativa: quién se encarga de la fiabilidad y la seguridad

Cuando la gente debate OpenAI API vs LLMs autohospedados, a menudo se enfocan en la calidad del modelo. En producción, la pregunta diaria más importante es: ¿quién se encarga del trabajo que mantiene el asistente seguro, rápido y disponible?

Con una API, gran parte del trabajo pesado lo maneja el proveedor. Con la auto‑instalación, tu equipo pasa a ser el proveedor. Puede ser la decisión correcta, pero es un compromiso real.

La carga operativa suele incluir desplegar el modelo y la pila de servicio (GPUs, escalado, backups), monitorizar latencia y errores con alertas fiables, parchear sistemas según calendario, rotar claves y credenciales y manejar outages y picos de capacidad sin romper la app.

Las actualizaciones de modelos son otra fuente de trabajo. Modelos autohospedados, drivers y motores de inferencia cambian con frecuencia. Cada cambio puede alterar respuestas en pequeños detalles que los usuarios notan como “el asistente empeoró”. Incluso con una API, las actualizaciones ocurren, pero no gestionas drivers de GPU o parches de kernel.

Una forma simple de reducir la deriva de calidad es tratar el asistente como cualquier otra funcionalidad y probarlo:

• Mantén un pequeño conjunto de preguntas reales como suite de regresión.
• Verifica fallos de seguridad (fugas de datos, consejos inseguros).
• Rastrea consistencia de respuestas en flujos clave (reembolsos, acceso a cuentas).
• Revisa una muestra de conversaciones semanalmente.

La seguridad no es solo “no salen datos de nuestros servidores”. También es gestión de secretos, logs de acceso y respuesta a incidentes. Si alguien consigue la clave del endpoint del modelo, ¿puede subirte la factura o extraer prompts sensibles? ¿Registras prompts de forma segura, con redacción para emails e IDs?

La realidad del on‑call importa. Si el asistente falla a las 2 a. m., un enfoque API a menudo significa degradar con gracia y reintentar. Un enfoque autohospedado puede significar que alguien se levante para arreglar un nodo GPU, un disco lleno o un despliegue fallido.

Si construyes en una plataforma como AppMaster, planifica estas tareas como parte de la función, no como algo posterior. El asistente es una superficie de producto. Necesita un responsable, runbooks y un plan claro de “qué pasa cuando falla”.

Un método práctico paso a paso para elegir el enfoque correcto

Empieza por tener claro qué quieres que haga el asistente dentro del producto. “Chat” no es un trabajo. Los trabajos son cosas que puedes probar: responder preguntas de tu documentación, redactar respuestas, enrutar tickets o tomar acciones como “restablecer contraseña” o “crear una factura”. Cuanto más pueda cambiar datos, más control y auditoría necesitarás.

A continuación, dibuja tu límite de privacidad. Lista los datos que el asistente podría ver (mensajes, detalles de cuenta, archivos, logs) y etiqueta cada ítem como baja, media o alta sensibilidad. Alto suele significar datos regulados, secretos o cualquier cosa dolorosa si se expone. Este paso a menudo decide si una API hospedada es aceptable, si necesitas redacción estricta o si algunas cargas deben quedarse en tus propios servidores.

Luego define objetivos que puedas medir. Sin números no puedes comparar opciones de forma justa. Escribe:

1. Un objetivo de latencia p95 para una respuesta típica (y un objetivo separado para flujos que toman acciones).
2. Un límite de gasto mensual y qué cuenta para él (tokens, GPUs, almacenamiento, tiempo de soporte).
3. Expectativas de disponibilidad y qué sucede cuando el modelo está caído.
4. Requisitos de seguridad (temas bloqueados, logging, revisión humana).
5. Un umbral de calidad y cómo puntuarás las “buenas” respuestas.

Con esas restricciones, elige una arquitectura que se ajuste a tu tolerancia al riesgo. Una API hospedada suele ser la forma más rápida de alcanzar calidad aceptable y mantiene baja la carga operativa. El auto‑hospedaje tiene sentido cuando los datos no pueden salir de tu entorno o cuando necesitas control más fino sobre actualizaciones y comportamiento. Muchos equipos acaban con un híbrido: un modelo principal para la mayoría de consultas y una vía de reserva cuando la latencia sube, se golpean cuotas o se detectan datos sensibles.

Finalmente, ejecuta un piloto pequeño con tráfico real, no prompts de demo. Por ejemplo, permite solo un flujo: “resumir un ticket de soporte y proponer una respuesta” y úsalo durante una semana. Mide latencia p95, coste por ticket resuelto y porcentaje de respuestas que necesitan edición. Si construyes en AppMaster, mantén el piloto estrecho: una pantalla, una fuente de datos, logs claros y un interruptor fácil de apagar.

Errores comunes que cometen los equipos (y cómo evitarlos)

Muchos equipos tratan esta elección como una decisión puramente de proveedor: OpenAI API vs LLMs autohospedados. La mayoría de los problemas en producción vienen de básicos que es fácil pasar por alto cuando te concentras en la calidad del modelo.

Error 1: Pensar que la auto‑instalación es privada por defecto

Ejecutar un modelo open‑source en tus servidores ayuda, pero no hace que los datos sean seguros automáticamente. Los prompts pueden acabar en logs de la app, herramientas de tracing, informes de error y backups de base de datos. Incluso impresiones de depuración “temporales” pueden volverse permanentes.

Evítalo definiendo una política clara de datos: qué está permitido en los prompts, dónde se almacenan (si se almacenan) y cuánto tiempo viven.

Error 2: Enviar datos de clientes sin procesar en los prompts

Es común pasar tickets completos, emails o perfiles al prompt porque “funciona mejor”. Eso también es cómo filtras números de teléfono, direcciones o datos de pago. Redacta primero y envía solo lo que el asistente necesita.

Una regla simple: envía resúmenes, no volcados. En vez de pegar un chat de soporte completo, extrae la última pregunta del cliente, el ID de pedido relevante y una breve nota de estado.

Error 3: No tener plan contra abuso (y facturas sorpresa)

Si el asistente está expuesto a usuarios, asume que alguien intentará inyección de prompt, spam o peticiones repetidas costosas. Esto afecta seguridad y coste.

Defensas prácticas que funcionan sin infraestructura pesada:

• Coloca el asistente detrás de autenticación y límites de tasa.
• Limita acciones de herramientas (como “reembolsar pedido” o “borrar cuenta”) a flujos explícitos y registrados.
• Añade límites de longitud de entrada y timeouts para parar prompts descontrolados.
• Monitoriza uso por usuario y por workspace, no solo tokens totales.
• Usa un modo “seguro” de fallback cuando las señales parezcan sospechosas.

Error 4: Lanzar sin evaluación

Los equipos suelen confiar en unas pocas conversaciones manuales y darlo por hecho. Luego una actualización de modelo, un cambio de prompt o un nuevo texto de producto rompe silenciosamente flujos clave.

Mantén un pequeño conjunto de pruebas que reflejen tareas reales: “restablecer contraseña”, “encontrar factura”, “explicar límites del plan”, “derivar a humano”. Ejecútalo antes de cada release y sigue resultados simples de aprobado/reprobado. Incluso 30‑50 ejemplos detectan la mayoría de regresiones.

Error 5: Sobreconstruir demasiado pronto

Comprar GPUs, añadir orquestación y afinar modelos antes de saber lo que los usuarios quieren es caro. Empieza con lo mínimo que pruebe valor, luego estabiliza.

Si construyes apps en AppMaster, un buen patrón temprano es mantener la lógica del asistente en un proceso de negocio controlado: sanitiza entradas, trae solo los campos necesarios y registra decisiones. Eso te da guardarraíles antes de escalar la infraestructura.

Lista rápida antes de lanzar un asistente a producción

Antes de liberar un asistente a usuarios reales, trátalo como cualquier otra función de producción: define límites, mídelo y planea fallos. Esto importa tanto si eliges OpenAI API como LLMs autohospedados, porque los puntos débiles tienden a verse similares en la app.

Empieza con reglas de datos. Escribe exactamente qué puede ver el modelo, no lo que esperas que vea. Una política simple como “solo asunto del ticket + últimos 3 mensajes” supera a la guía vaga.

Una checklist práctica antes del lanzamiento:

• Datos: Lista campos permitidos (y prohibidos). Enmascara o elimina secretos como contraseñas, datos completos de pago, tokens de acceso y direcciones completas. Decide cuánto tiempo se almacenan prompts y respuestas y quién puede verlos.
• Rendimiento: Fija un objetivo de latencia p95 (por ejemplo, menos de 3 segundos para una respuesta corta). Define un timeout duro y un mensaje de fallback que aún ayude al usuario a avanzar.
• Coste: Añade límites por usuario (por minuto y por día), alertas de anomalías para picos y un tope mensual que falle de forma segura en lugar de sorprenderte con la factura.
• Calidad: Construye un pequeño conjunto de evaluación (20 a 50 preguntas reales) y define qué significa “bueno”. Añade un proceso ligero de revisión para cambios de prompt y swaps de modelo.
• Ops: Monitoriza tasa de éxito, latencia y coste por petición. Registra errores con contexto suficiente para depurar sin exponer datos privados. Asigna un responsable de incidentes y un camino de on‑call.

El rendimiento se pierde a menudo en lugares que la gente olvida: consultas de recuperación lentas, contexto sobredimensionado o reintentos que se acumulan. Si el asistente no puede responder a tiempo, debe decirlo claramente y ofrecer la siguiente mejor acción (sugerir una búsqueda o derivar a soporte).

Un ejemplo concreto: en un portal de clientes, deja que el asistente lea estado de pedidos y artículos de ayuda, pero bloquéalo de ver campos de pago en bruto. Si construyes el portal en una herramienta no‑code como AppMaster, aplica las mismas reglas en tus modelos de datos y lógica de negocio para que el asistente no pueda eludirlas cuando un prompt se vuelva creativo.

Escenario de ejemplo: un asistente de portal de clientes con restricciones reales

Un minorista mediano quiere un asistente dentro de su portal de clientes. Los clientes preguntan “¿Dónde está mi pedido?”, “¿Puedo cambiar la dirección de entrega?” y preguntas frecuentes sobre devoluciones y garantía. El asistente debe responder rápido y no puede filtrar datos personales.

El asistente necesita solo una pequeña porción de datos para ser útil: un ID de pedido, el estado actual del envío (empaquetado, enviado, en reparto, entregado) y algunas marcas temporales. No necesita direcciones completas, detalles de pago, mensajes de clientes o notas internas.

Una regla práctica es definir dos cubos de datos:

• Permitido: ID de pedido, código de estado, nombre del transportista, fecha estimada de entrega, texto de la política de devoluciones
• Nunca enviar: nombre completo, dirección, email, teléfono, información de pago, notas internas de agentes

Opción A: OpenAI API para un lanzamiento rápido

Si eliges la API para velocidad, trata el modelo como una capa de redacción, no como una base de datos. Mantén los hechos en tu sistema y pasa solo contexto mínimo y redactado.

Por ejemplo, tu backend puede obtener el estado del pedido de la base de datos y luego enviar al modelo: “Pedido 74192 está Enviado. ETA: 31 Ene. Proporciona una actualización amigable y ofrece próximos pasos si la entrega se retrasa.” Eso evita enviar registros de cliente completos.

Las reglas importan aquí: redacta campos antes de promptar, bloquea intentos de inyección de prompt (“ignora instrucciones anteriores”) y registra lo que enviaste para auditoría. También necesitas un fallback claro: si la respuesta del modelo es lenta o incierta, muestra la página de estado normal.

Opción B: Modelo autohospedado para límites más estrictos

Si tu línea de privacidad es “ningún dato de cliente sale de nuestra red”, el auto‑hospedaje puede encajar mejor. Pero convierte al asistente en una función operativa que debes mantener: GPUs, escalado, monitorización, parches y un plan de on‑call.

Un plan realista incluye tiempo de personal (alguien responsable del servidor de modelos), presupuesto para al menos una máquina GPU y pruebas de carga. La latencia puede ser excelente si el modelo está cerca de tus servidores de app, pero solo si dimensionas hardware para picos.

Un híbrido simple que suele funcionar

Usa un modelo autohospedado (o incluso reglas) para pasos sensibles como obtener estado de pedido y validar identidad, y usa un modelo API solo para redacción general y respuestas de FAQ que no incluyan datos personales. Si construyes el portal con una plataforma no‑code como AppMaster, puedes mantener el acceso a datos y las reglas de negocio en el backend y reemplazar más tarde el “escritor de respuestas” sin reescribir todo el portal.

Próximos pasos: decidir, pilotar y construir sin sobrecomprometerse

Un asistente en producción no es una decisión que tomas una vez. Trátalo como una función que puedes revisar: elección de modelo, prompts, herramientas e incluso límites de privacidad cambiarán tras la interacción con usuarios reales.

Empieza con un flujo que ya tenga valor claro y límites claros. “Ayúdame a encontrar mi última factura y explicar los cargos” es más fácil de medir y más seguro que “Responde cualquier cosa sobre mi cuenta”. Elige un lugar en el producto donde el asistente hoy ahorre tiempo, y define qué significa “mejor”.

Un plan de piloto simple que puedes ejecutar en 1–2 semanas

Escribe las reglas primero y luego construye:

• Elige una tarea de alto valor y un grupo de usuarios (por ejemplo, solo administradores).
• Fija métricas de éxito (tasa de completitud de la tarea, tiempo ahorrado, derivación a humano, satisfacción de usuarios).
• Define una política de datos en lenguaje claro: qué puede ver el asistente, qué nunca, límites de retención y requisitos de auditoría.
• Construye una versión delgada que solo lea de fuentes aprobadas (docs, un conjunto limitado de campos de cuenta) y registre cada respuesta.
• Ejecuta un piloto corto, revisa fallos y decide: ampliar, cambiar enfoque o parar.

Las políticas importan más que la elección del proveedor. Si tu política dice “los mensajes crudos de clientes nunca salen de nuestro sistema”, eso te empuja hacia auto‑hospedaje o redacción fuerte. Si tu política permite enviar contexto limitado, una API puede ser la forma rápida de validar la función.

Planifica el cambio desde el día uno

Aunque empieces con un modelo, asume que lo cambiarás, actualizarás prompts y afinarás la recuperación. Mantén un pequeño conjunto de regresión: 30 a 50 preguntas reales anonimizadas con ejemplos de respuestas aceptables. Reejecútalo cada vez que cambies prompt, herramientas o versión de modelo y vigila fallos nuevos como respuestas seguras pero incorrectas.

Si quieres que el asistente sea una función real del producto (no solo una caja de chat), planifica todo el camino: comprobaciones en backend, estados de IU y comportamiento móvil. AppMaster (appmaster.io) puede ayudarte a construir la lógica backend, la IU web y pantallas nativas móviles juntas, iterar rápido y mantener las reglas de acceso a datos en un solo lugar. Cuando estés listo, puedes desplegar en tu cloud o exportar el código fuente.