Preguntas frecuentes de IA

El chatbot está en la web y responde a quien escribe. El agente vive detrás, tiene acceso a tus sistemas y termina tareas: consulta el CRM, crea un informe, manda un correo o actualiza un registro. También tiene límites, memoria y registro de lo que hace. El chatbot mejora la experiencia de quien pregunta; el agente reduce trabajo a tu equipo.

Puede, y por eso el diseño no parte de que no lo haga. Hay acciones de bajo riesgo que se ejecutan solas, acciones que exigen aprobación y acciones bloqueadas. Todo queda registrado, se revisa por tipo de tarea y se corrige el prompt o las reglas. Un agente sin registro no lo desplegamos.

Normalmente no. Necesitamos que tus sistemas ofrezcan una vía de lectura y, si el agente actúa, de escritura: una API, un webhook, un connector de n8n o una exportación periódica. Cuando la API no existe, la solución es una capa intermedia, no un rediseño de tu CRM.

El coste variable es el del modelo por token y el de las integraciones que uses. El fijo es el mantenimiento. Revisar los fallos, actualizar los prompts cuando cambia el proceso y auditar las llamadas. Lo presupuestamos por horas al mes, no como una cuota cerrada, porque el uso real se ve a las pocas semanas.

Depende del despliegue que elijas. Con modelos de pago, la información viaja al proveedor según su contrato y se abre con acuerdo de confidencialidad. Con modelos locales o despliegue on-premise, el dato no sale de tu infraestructura. En el briefing te decimos qué implicación tiene cada opción antes de empezar.

Un agente con un proceso acotado suele estar en producción en dos a cuatro semanas: una de diagnóstico y diseño, otra de construcción y las últimas de prueba en paralelo. Si hay que montar integraciones que no existían, se alarga. En el briefing te damos el calendario con el alcance cerrado.

Un asistente que responde lo mismo que tu mejor comercial en las preguntas que se repiten cien veces a la semana. Con la documentación de tu empresa, con límites claros y con salida a un humano cuando la conversación lo necesita. Lee la guía completa de Inteligencia Artificial para el contexto teórico.

El trabajo se entrega por fases y con entregables cerrados: SEO avanzado, Performance (SEM), Redes Sociales, Content Marketing. Cada entregable lleva responsable y fecha, y se mide contra los KPIs acordados antes de empezar.

La estrategia se define en 48 horas y el resto se planifica por sprints, con entregables y responsables en cada uno. El presupuesto se calcula tras una auditoría gratuita previa, en función del alcance, el estado actual y los objetivos de tu negocio: no hay precios cerrados porque no hay dos proyectos iguales.

Con datos de tu propio negocio, no con métricas de vanidad: conversión, leads cualificados, revenue atribuido y coste de adquisición. Configuramos el tracking en GA4 y el reporting mensual con los KPIs que tu equipo usa para decidir.

Puedes contratar este servicio por separado o combinarlo con los packs preconfigurados de Netbulb. Cuando el servicio funciona mejor acompañado, te lo decimos en la auditoría antes de presupuestar.

Con un buen modelo de síntesis y un guion bien escrito, no. Se nota más en los silencios y en las interrupciones que el bot no controla que en la voz. Por eso probamos llamadas reales antes de publicar.

Se transfiere con el resumen de lo tratado y los datos ya confirmados, sin repetir lo que el bot ya preguntó.

Sí. Se usa para confirmaciones, avisos, recordatorios, encuestas y sondeos, con lista de supresión y horario permitido por la normativa de llamadas.

Depende de la duración, del proveedor de voz y de lo que haga el bot con la agenda. Antes de empezar te damos el coste por minuto y el coste por llamada resuelta, para que puedas compararlo con el coste de una persona.

El modelo transcribe con vocabulario del sector y pide confirmación de los datos críticos. Si hay dos 이해idos, nunca se da por bueno un número sin repetirlo.

Entre cuatro y ocho semanas. La voz está lista en semanas, pero el guion hablado necesita escucharse en llamadas reales antes de confiarse: ese es el trabajo que más calidad y tiempo se lleva.

Por eso el supervisor decide quién participa. El presupuesto por tarea limita el gasto y las stopping rules cortan la cadena cuando el resultado ya es suficiente. Medimos el coste por tarea y lo ajustamos con los datos.

El que mejor encaja con el proceso: LangGraph para grafos con estado, CrewAI para equipos con roles, o n8n cuando el flujo tiene muchas integraciones y poca lógica. La decisión se toma en el diseño, no por defecto.

Con contratos de salida: cada agente devuelve un formato fijo, el validador lo comprueba contra criterios y el supervisor solo entrega lo que ha pasado la validación. Las fuentes van citadas en el resultado.

Suele bastar con un solo agente. La mayor parte de los casos resuelve con un agente bien hecho. La cadena tiene sentido cuando el proceso tiene partes heterogéneas o cuando hace falta una segunda opinión independiente.

Con casos reales del negocio evaluados por personas y por automación: acierto, utilidad, cobertura y coste por tarea. Cada cambio del supervisor se prueba contra ese conjunto antes de publicar.

Un flujo con dos o tres agentes suele estar en semanas. Con debate, validación cruzada y panel de coste, el plazo normal es de uno a dos meses, con una primera versión simple en producción a las cuatro semanas.

No. El motor hace el 80% del trabajo mecánico: research, borrador, estructura y controles. La línea editorial, la revisión final y la priorización siguen siendo de una persona. Si el contenido no lo aprueba nadie, no se publica.

Reduce mucho el riesgo: el motor compara con lo ya publicado, evita repeticiones del mismo cluster y trabaja con fuentes propias. Aun así, un sitio con contenido generado sin valor añadido no posicionará. La calidad editorial sigue siendo la variable que decide.

El que mejor encaje con la tarea: modelos frontier para el texto que exige criterio y modelos menores para clasificar, etiquetar o resumir. El coste por pieza se decide con el número de piezas, no con la marca del modelo.

Depende de la profundidad del research, del número de revisiones y del modelo. Publicamos un coste por pieza terminado antes de empezar, con tres niveles de profundidad para que elijas.

Sí, si el tono está escrito. Definimos la voz con ejemplos, reglas y una lista de expresiones prohibidas, y el motor la aplica y la verifica en cada pieza.

De dos a cuatro semanas para el piloto con un canal, y un mes más para escalar a los demás. El primer mes se dedica a calibrar el motor con las piezas que hace el equipo.

La imágen es coherente y creible, pero no es una foto real. Para piezas de marca, ilustración, lifestyle y backgrounds funciona muy bien; para fichas de producto donde la fidelidad al artículo es clave, recomendamos fotografía real y usar la IA en el resto.

Las imágenes se generan en herramientas con licencia comercial para uso empresarial. Revisamos las condiciones de cada proveedor en el momento de la producción y te lo dejamos por escrito en la entrega.

Entre una y dos semanas con un lote de fotografías de referencia. A partir de ahí, la producción es inmediata y solo se ajusta si cambias la línea visual.

Sí, con las autorizaciones y las restricciones que marca cada plataforma. Para piezas de personas identificables recomendamos Consentimiento escrito y una revisión legal del uso.

Depende del modelo y de la resolución final. Para digital es más que suficiente; para impresión en gran formato entregamos archivos en alta y retocados, y te decimos cuando conviene remasterizar con fotografía real.

Se presupuesta por pieza y por tanda, con tres niveles: concepto, pieza final y pieza final con retoque. El coste es más bajo que el de una sesión de fotografía, y la capacidad de producción es mucho mayor.

Para piezas cortas de social y previsualizaciones, sí. Los modelos actuales resuelven movimiento, luz y encuadre con naturalidad. Para piezas de marca larga o con voz y gestos complejos, la IA se usa como apoyo y el rodado real sigue siendo la opción.

Con imágenes de referencia y keyframes consistentes, el personaje se mantiene con razonable fidelidad entre clips. Para el mismo personaje en continuidad completa, el trabajo por tomas es la via fiable.

Podemos usar voz sintetica con la de tu marca o grabar la voz real y montar la pieza. Si hay personas identificables, la autorización es obligatoria y la revisamos antes de publicar.

Un spot de quince segundos se genera y edita en una jornada, y una tanda de cuatro variantes en dos o tres. El cuello de botella es la generación en alta, no el trabajo creativo.

Se presupuesta por pieza y por resolución, con el coste de render y de postproducción separados. Para piezas sociales es una fracción del coste de un rodaje equivalente.

Gestionamos los derechos de las herramientas, la ausencia de marcas de agua y la autorización de personas y voz. Las piezas de marca se revisan con el legal del cliente antes de publicarse.

Histórico de ventas a nivel de producto o serie, con fecha, cantidad y precio. Con eso se puede empezar. Si el histórico no existe, la primera fase es estimar una curva base, y eso ya tiene valor.

Es lo más común y se resuelve. El diagnóstico ordena los datos, define la granularidad y marca los huecos. Un modelo sin datos limpios da números precisos sobre la realidad equivocada.

Sí, y es la parte importante. Cada previsión se publica con su instantánea de datos, su calendario de negocio y sus intervalos. Si el plan comercial cambia, se ve exactamente qué parte del forecast se ha movido.

El forecast usa el plan de marketing, la estacionalidad real del negocio y las variables externas; además entrega escenarios y alertas. La estadística mira hacia atrás y no sabe nada de lo que vais a hacer.

Al ritmo que cambia el negocio. En retail, semanal; en industria, mensual con actualización semanal de alertas. Publicar más a menudo de lo que cambia el dato solo genera ruido.

Entre cuatro y seis semanas hasta el primer forecast en producción, con la validación hecha. Los escenarios y la integración con el ERP se añaden en la segunda fase.

Histórico de clientes con al menos un periodo de churn ya cerrado, y datos de comportamiento por cliente. Con pocas suscripciones nuevas, el primer modelo se construye con cohortes antiguas o se espera a tener la primera seña de bajas.

Las que describen comportamiento: frecuencia de uso, recencia, tickets de soporte, uso de funciones, patrones de pago y señales de satisfacción. Los datos demográficos se usan con cautela y nunca como único predictor.

El modelo calcula la probabilidad y los factores que más pesan en cada caso. No explica la intención profunda, pero sí señala los patrones que se repiten en las bajas reales, que es lo que ayuda a actuar.

Se trabaja con datos agregados y se respetan las bases jurídicas. Cuando el cliente es identificable, el tratamiento se pacta por escrito y se limita a lo estrictamente necesario.

El score y el motivo se escriben en el CRM y en el panel comercial, con una tarea asociada y una fecha. El comercial ve a quién llamar, por qué y qué hacer.

De seis a diez semanas hasta el primer scoring en manos del equipo, con la validación incluida. La integración con el CRM se añade en la segunda fase.

Histórico de leads con su resultado (cerrado o no) y, para entrenar, al menos varios cientos de casos. El comportamiento en la web y las interacciones con el comercial son los que más peso tienen.

Se trabaja con lo que haya: datos de CRM, interacciones, sector, presupuesto y señales. Con menos datos el modelo tiene menos potencia, y eso te lo decimos antes de empezar.

Trabajamos con datos propios y con fuentes con licencia clara. Los enrichment de terceros se usan solo si su uso está autorizado, y eso se revisa caso por caso.

Un score es una estimación, no una verdad. Se valida con corte temporal y se calibra con la realidad, y se usa para ordenar el trabajo, no para decidir automáticamente a quién se le cierra.

Por API o con las integraciones nativas de HubSpot, Salesforce o Pipedrive. El score, el motivo y la tarea se escriben en el lead para que el comercial no tenga que abrir otra herramienta.

De seis a ocho semanas hasta la primera lista automatizada, y después se entrega semanalmente con mantenimiento mínimo.

Funciona mejor en sectores con demanda estacional, launches, modas o consumibles. En servicios B2B puros la señal es más débil y el radar aporta menos. Lo decimos en el diagnóstico.

Con una frecuencia diaria o semanal, según la velocidad del sector. En retail moda se recomienda diario; en ciclos largos, semanal.

Entre dos y seis semanas según el sector. Lo calibramos con tu histórico: si en los últimos años las tendencias se precedieron a la venta, te decimos cuánto margen real tienes.

Sí, por eso normalizamos y exigimos un cambio de pendiente sostenido, no un pico. Las señales se validan contra la venta real y las que no sirven se retiran del radar.

Google Trends, Reddit, Hacker News, X, YouTube, webs de reseñas y medios del sector, con términos propios de tu negocio. Las fuentes con licencia se documentan.

Tres o cuatro semanas hasta el radar en funcionamiento, y un mes más para calibrarlo con datos de venta reales. A partir de ahí, el mantenimiento es mensual.

Un mínimo de imágenes por producto y categoría, y en alguns casos fotos con atributos etiquetados. Con modelos preentrenados, muchas marcas arrancan sin entrenar nada y luego afinan.

En categorías con textura y forma clara, la similitud visual es alta. En productos muy parecidos entre sí, como dos modelos del mismo producto en distintos colores, se afina con más datos y con reglas de color.

Con dos capas: un filtro automático que descarta lo claramente no permitido y una cola de revisión humana para los casos dudosos. Nada se publica sin pasar el filtro, y el sistema aprende de las decisiones del equipo.

Sí. La cámara del móvil se integra en el buscador y el resultado es una lista de productos con la confianza de la coincidencia.

Moderado si el catálogo no es enorme: los embeddings se precalculan y la búsqueda es rápida. Para catálogos de millones de referencias usamos almacenamiento vectorial con coste por consulta.

De cuatro a seis semanas hasta la búsqueda por imagen funcionando, y dos semanas más para la moderación automática de UGC. El etiquetado del catálogo completo depende del volumen.

El OCR normal devuelve texto. Este devuelve campos, con la confianza de cada uno y con validaciones cruzadas. En una factura con notas y columnas, esa diferencia es todo el trabajo.

Sí. El reconocimiento de texto funciona bien en varios idiomas y la comprensión del documento se ajusta al idioma del negocio. Si trabajas en varios, se configuran varias plantillas.

Se detectan y van a revisión manual. El sistema aprende de las correcciones, de modo que los escaneos problemáticos de un proveedor se resuelven solos tras unas semanas.

Con la API, el SFTP o la exportación periódica según el ERP. Escribimos los campos validados con su referencia cruzada para poder auditar de dónde salió cada dato.

El tratamiento se pacta y el despliegue puede ser on-premise cuando lo requiere. El sistema cumple los controles de acceso y retención que acordemos, y se puede limitar a documentos sin datos sensibles.

Entre cuatro y ocho semanas según el número de tipos de documento. El primer tipo suele estar en dos semanas; a partir de ahí, cada tipo nuevo cuesta mucho menos.

Depende del uso y del país. Para analíticas agregadas de tráfico y permanencia, con información no identificable, el marco habitual lo permite si hay información clara al visitante. Para reconocimiento de personas, hay restricciones serias. Revisamos el caso concreto con tu documentación antes de empezar.

Cámaras IP o cámaras de vídeo ya instaladas, con calidad suficiente para el análisis. No hace falta cámara nueva en la mayoría parte de los casos; a veces basta con cambiar el ángulo.

Se calcula por cámara y por franja. Con procesamiento en la nube el coste es por hora de vídeo analizado; con tarjeta en la propia tienda, es una inversión de hardware que se amortigua con el volumen.

Tráfico, permanencia, recorridos, conversión por zona, uso del lineal, tiempos de espera y eventos anómalos. Lo que no hacemos es identificar ni perfilar a personas.

Sí. El mismo análisis se aplica por lotes al archivo, lo que permite analizar retrospectivamente incidencia y medir la mejora de una reorganización del lineal.

De seis a ocho semanas hasta el primer panel con datos de un punto concreto, incluida la calibración del modelo con tus cámaras.

El RFM agrupa por tres variables y produce grupos amplios. Los embeddings añaden el comportamiento real y el contexto de compra, de modo que los grupos son más finos y más fáciles de activar. Es una evolución, no un reemplazo.

Histórico de compras o de interacción de al menos seis meses, con cliente identificable y eventos con fecha. Con eso se construye el perfil; sin eso, no hay segmentación que aguante.

Modelos de embedding para texto y comportamiento, KMeans o HDBSCAN para agrupar y una validación de estabilidad con índice silhouette y con el propio negocio. Todo queda en un pipeline reproducible.

Esa es la pregunta clave. Se testea la estabilidad en el tiempo y se fija un mínimo. Si un grupo se deshace cada trimestre, se fusiona con otro o se rediseña la segmentación.

No se usan atributos sensibles para segmentar y el tratamiento se pacta por escrito. Los perfiles se agregan y se puede limitar el uso a finalidades de comunicación comercial con el consentimiento adecuado.

De seis a ocho semanas hasta la segmentación validada y el plan de acción por grupo, con una primera activación medida al trimestre siguiente.

Google, App Store, Amazon, Trustpilot, tickets de soporte, encuestas, NPS, llamadas transcritas y redes sociales. Cada fuente con su permisos y su válculo de acceso.

Con un modelo entrenado con tus datos y un conjunto de validación humano, se llega a un acuerdo alto con las personas. Para decisiones de marca, el tema se revisa con el equipo antes de actuar.

Los modelos actuales gestionan bien el lenguaje informal, pero el sarcasmo sigue siendo el punto débil. Por eso el sistema agrupa temas y no se queda solo con la etiqueta de sentimiento, y las alertas graves se revisan a mano.

Sí, si se recoge de las mismas fuentes públicas. Es una de las lecturas más útiles: no solo saber qué dicen de tí, sino qué dicen de ellos.

Se analiza de forma agregada y se evita el tratamiento de datos sensibles. Los casos individuales que se revisan manualmente se gestionan con los permisos de tu equipo.

De cuatro a seis semanas hasta el primer panel y las primeras alertas, con la calibración del modelo con ejemplos reales del negocio.

El clustering agrupa por significado, no por palabras. Detecta que dos artículos con distinto vocabulario hablan de lo mismo, y eso es lo que permite ver la saturación real de un tema.

A partir de unos cientos el modelo empieza a ser interpretable. Con miles de documentos el resultado es sólido y con decenas de miles, muy util. Por debajo de esa cifra, el mapa no es fiable.

BERTopic cuando se quiere agrupar con etiquetas interpretables, LDA para textos cortos y limpios, y embeddings con KMeans cuando hay mucho documento y muchos idiomas. Se comparan con el mismo corpus y se elige el más util.

Sí, y funciona mejor que en inglés si el corpus es grande. Con documentos cortos, el modelo multilingü pierde algo de precisión y hay que compensar con más volumen.

Con negocio, no en solitario. El mapa se lee en una sesión de dos horas con el equipo editorial: se valida cada topic, se renombran y se decide qué hacer con cada uno.

De tres a cinco semanas para el primer mapa completo, más una sesión de lectura con el equipo. El mantenimiento es trimestral.

Para construir un workflow básico, no. n8n es visual y las tareas más comunes se montan arrastrando nodos. Para lógica compleja, expressions o código en un nodo, sí hace falta algo de programación, y lo escribimos nosotros.

Sí. La versión self-hosted no tiene coste de licencia y los datos no salen de tu infraestructura. Es la opción habitual cuando hay datos sensibles.

El flujo reintenta con espera progresiva, aplica la ruta alternativa si existe y, si no, avisa al canal con el contexto. Ninguna ejecución se pierde en silencio.

Se mide por workflow: el sistema registra los tokens de cada paso con IA. Antes de construir te damos una estimación de coste mensual y revisamos el consumo en el panel.

Más de 400 en n8n, además de las APIs propias por HTTP. Cubrimos CRM, correo, calendario, hojas de cálculo, ERP, pasarelas de pago y herramientas de marketing.

De dos a cuatro semanas por proceso, con las pruebas en paralelo al trabajo manual. El primero suele ser el más rápido; los siguientes, mucho más rápidos.

WordPress y WooCommerce, Shopify, HubSpot, Salesforce, Pipedrive, SAP, Holded, PrestaShop, Zoho y cualquier API con webhook o REST. Si la plataforma no tiene API, se construye una capa intermedia.

Puede, pero solo con validación previa. Definimos los campos que puede rellenar, los que nunca toca y los que exigen aprobación humana. Un ERP sin reglas claras se llena de basura.

Cada campo tiene una prioridad definida. Cuando llega un cambio por los dos lados, se aplica la regla y se registra el conflicto para revisarlo. Nada se sobrescribe en silencio.

Sí, con webhooks, o por lotes si la plataforma lo exige. Para catálogos grandes, la sincronización por lotes cada pocos minutos suele ser suficiente y más barata.

El modelo solo propone y un validador comprueba formato, coherencia y valores permitidos antes de escribir. Si algo no cuadra, el registro queda en cola de revisión con el motivo.

De tres a seis semanas por integración, según el número de plataformas y el volumen. La primera es la más lenta; el resto se acelera con los patrones ya montados.

El ETL normal aplica reglas fijas y se rompe con cada formato nuevo. El pipeline con IA reconoce el contenido, clasifica, deduplica por similitud y explica cada decisión, de modo que se adapta sin reescribir reglas.

En tu nube de datos (BigQuery, Snowflake, Redshift, Databricks) o en un worker propio, con la lógica de IA como paso del pipeline. El dato no sale de tu infraestructura si no quieres.

Cientos de miles de registros por lote se procesan sin problema. Para volúmanes de millones se partitiona y se usa procesamiento distribuido.

Sí. Cada transformación se registra con su entrada, su salida, su prompt y su confianza. Si un registro se descarta, se puede ver exactamente por qué.

La validación de calidad bloquea la carga cuando los métricas se degradan y los casos dudosos van a la cola de revisión. Además, cada corrección manual se usa para reentrenar el modelo.

De cuatro a ocho semanas hasta el pipeline en producción con medición de calidad, y las primeras métricas de ahorro en el siguiente ciclo.

El RPA clásico graba las coordenadas de cada clic y se rompe si cambia un botón. El agente ve la pantalla, entiende el contexto y decide la acción siguiente. La diferencia se nota en los sistemas que cambian poco a poco.

Esa es justo la razón de existir del servicio. El robot trabaja sobre la interfaz, igual que lo haría una persona, pero sin cansarse ni equivocarse de ventana.

El agente puede adaptarse si el cambio es ligero. Si el sistema cambia de forma estructural, se recalibra el robot. En los casos críticos se avisa y la tarea queda en la cola de excepción.

Cada acción se comprueba en pantalla y se guarda la evidencia. Con un número máximo de intentos y una regla de parada, el robot nunca deja una tarea a medias sin avisar.

Por eso se empieza por tareas de bajo riesgo, se limita el alcance del robot y se mantiene la aprobación humana en las acciones críticas. Los límites se definen con negocio antes de empezar.

De cuatro a ocho semanas por proceso, con un mes de convivencia en híbrido. El ahorro aparece cuando el robot pasa a cerrar tareas de forma autónoma.

Dos o tres semanas de trabajo de campo y una sesión de entrega. Con equipos distribuidos o multinationales, se suele alargar una semana por la disponibilidad de las entrevistas.

Un informe de madurez por área, un mapa de iniciativas con su impacto y esfuerzo, una hoja de ruta a doce meses y el material para defenderla ante el comité.

El informe se puede escribir para que lo valide tu comité o para que lo presente tu proveedor. Recomendamos la primera: es la que se sostiene en el tiempo.

No. Recomendamos evitar herramientas cuando no aporta valor, y eso incluye las nuestras. Cuando la recomendación sea usar IA, lo hacemos con nuestro equipo.

Con el volumen y el coste actual de cada proceso, una estimación de tiempo ahorrado y una asignación de coste por hora. Se documenta cada supuesto para que se pueda corregir con tus números.

El acompañamiento en los primeros meses: la hoja de ruta se revisa con los datos reales y se ajusta. Una auditoría sin seguimiento es un informe caro.

Un buen prompt es una instrucción buena. Prompt engineering es el trabajo completo: instrucción, contexto, esquema de salida, pruebas, versión y medición. Lo segundo es lo que aguanta en producción.

Depende de la tarea: chain-of-thought para razonamiento, few-shot para formato y tono, tree-of-thoughts y self-consistency para decisiones complejas, function calling y structured outputs para que la respuesta se pueda usar.

Para mantener una batería de pruebas y versionar, ayuda. Para escribir y mejorar los prompts, no. Lo habitual es que lo haga el equipo de negocio con soporte técnico.

Con un conjunto de casos con su respuesta esperada y una métrica clara: acierto, formato válido o puntuación humana. Sin eso, la comparación de versiones es una opinión.

Puede. Por eso el prompt se versiona junto con el modelo con el que se probó y la batería de pruebas se ejecuta en cada actualización del proveedor.

De dos a cuatro semanas para el primer sistema de prompts medido en un proceso crítico. El resto se replica con la misma plataforma y la misma metodología.

Cuando la tarea es estable, hay volumen alto y el prompt con contexto no llega al objetivo. Con poco volumen, un buen prompt con RAG sale más barato y se mantiene mejor.

Depende de la tarea, pero como orden de magnitud: cientos de ejemplos bien etiquetados para clasificar, miles para afinar el tono. Con menos de 200 el overfitting está casi asegurado.

Sí. Los modelos open-source como Llama, Mistral o Qwen se despliegan con vLLM o TGI en tu infraestructura, con cuantización para no necesitar GPU de centro de datos.

Con QLoRA, una GPU de 24 GB basta para entrenar y un equipo modesto para inferencia. Para un volumen alto, varias GPUs o cuantización a 4 bits.

Precisión, exhaustividad y calidad de la respuesta con RAGAS, con métricas propias de la tarea y con un conjunto de casos humanos. Sin evaluación, el afinado es adivinar.

De seis a diez semanas: dos de datos, dos de entrenamiento y evaluación, y el resto de despliegue y comparativa. El primer fine-tuning suele ser el más lento; los siguientes, con los datos ya listos, van en semanas.

Por el inventario. No se puede gobernar lo que no se ha listado, y el inventario por sí solo ya suele revelar sistemas que nadie sabía que existían. Después, la clasificación de riesgo.

Obligaciones escalonadas por categoría de riesgo: desde la transparencia en los chatbots hasta requisitos de gestión de riesgos, documentación, registro y supervisión humana en los sistemas de alto riesgo. El calendario de aplicación por bloques es lo que hay que tener claro.

No. El AI Act aplica a cualquier empresa que opere en la UE y a clientes corporativos que piden garantias. El GDPR además obliga a todo el que trate datos personales.

El documento que describe el sistema: propósito, datos, arquitectura, métricas, riesgos, controles, responsable y versión. Es lo que se pide en una auditoría y lo que obliga a tener el control real.

Se mide el resultado por grupo relevante, se compara con la referencia y se documenta la diferencia. Si hay desviación relevante, se corrige o se restringe el uso del sistema.

De seis a diez semanas para el marco completo en una organización de tamaño medio, con el inventario en dos semanas. La actualización es periódica y se apoya en los equipos, no en un consultor.