Fine-tuning, RAG o prompt: el compromiso en la gobernanza de datos

Hay tres formas de darle tu dominio a un modelo generalista. Puedes hacer fine-tuning, cociendo tus datos en los pesos. Puedes recuperar, trayendo tus datos en tiempo de ejecución y entregándoselos al modelo como contexto. O puedes instruir, describiendo tu dominio en las instrucciones de cada llamada. La mayoría de los equipos elige entre ellas por capacidad y coste: cuál hace al modelo más preciso, por el menor dinero y esfuerzo.

Solo que, en una empresa regulada, esas son las preguntas secundarias. La principal es dónde acaban viviendo tus datos regulados, porque ese único hecho decide si puedes auditar el sistema, borrar los datos de una persona cuando lo pida y actualizar tu conocimiento de dominio sin un proyecto de reentrenamiento. La elección entre fine-tuning, RAG y prompt es una decisión de gobernanza de datos disfrazada de ingeniería. Elige solo por precisión y puedes acorralarte en una arquitectura donde una petición rutinaria de derecho al borrado significa reentrenar un modelo.

La forma de elegir bien es dejar de preguntar qué técnica es más capaz y empezar a preguntar dónde pone cada una tus datos regulados, y cuánto te cuesta esa ubicación cuando un regulador, un cliente o tu propio proceso de cambios llame a la puerta.

Dónde viven los datos: cocidos, recuperados o en contexto

Los tres enfoques difieren en un eje que gobierna todo lo demás: la persistencia y la ubicación de tus datos regulados respecto al modelo.

El fine-tuning cuece los datos en los pesos. Coges ejemplos de tu dominio, a menudo con registros reales, y entrenas el modelo con ellos. Después del entrenamiento, esa información queda difundida por miles de millones de parámetros. Deja de ser un documento que puedas señalar. Es un residuo estadístico distribuido por el modelo, y el modelo puede reproducirlo en una salida sin "recuperarlo" nunca, porque nunca se guardó como algo recuperable. Es la forma más íntima de enseñar, y la menos reversible.

RAG mantiene los datos en un almacén que el modelo lee en tiempo de ejecución. Tu contenido regulado se queda en una base de datos o índice que es tuyo. En el momento de la consulta, la pieza relevante se trae y se coloca en la ventana de contexto, se usa para esa respuesta y luego desaparece desde el punto de vista del modelo. Los pesos del modelo nunca cambian. Los datos viven donde los pusiste, bajo tus controles de acceso, y el modelo los toma prestados un instante.

El prompt pone los datos en la instrucción, en contexto, por llamada. Nada persiste. El conocimiento de dominio se describe o se aporta en el prompt, se usa en esa única inferencia y se descarta. Es la opción más transitoria: el modelo aprende tu dominio durante una llamada de API y lo olvida por completo después.

El mismo objetivo, tres perfiles de gobernanza de datos radicalmente distintos. El resto de la decisión se sigue de esta distinción.

Auditabilidad y derecho al borrado: las preguntas que un regulador hará de verdad

Dos obligaciones exponen la diferencia con nitidez, y las dos son rutina en una casa regulada.

Considera la auditabilidad. Un regulador pregunta: ¿qué información usó el sistema para llegar a esta decisión, y puedes enseñármela? Con RAG, la respuesta es limpia. Se recuperaron estos documentos concretos, en esta versión del índice, y la decisión derivó de ellos; el rastro de evidencias nombra las fuentes. Con prompt, es igual de limpia: el contexto se montó a partir de estas entradas, aquí están. Con un modelo afinado por fine-tuning, la respuesta honesta es incómoda. La decisión se apoyó en conocimiento difundido por los pesos durante el entrenamiento, y no puedes señalar el registro concreto que la moldeó. Puedes describir el conjunto de entrenamiento; no puedes rastrear una salida concreta hasta una entrada concreta. Para un proceso donde cada decisión necesita una base inspeccionable, eso es un problema estructural, no una brecha de documentación.

Ahora considera el derecho al borrado. Una persona ejerce su derecho a que se borren sus datos. Si su registro estaba en un almacén RAG, borras el registro y desaparece de las recuperaciones futuras, de inmediato y de forma demostrable. Si solo estuvo en prompts, nunca se persistió; no hay nada que borrar. Pero si sus datos se cocieron en un modelo afinado, borrarlos es genuinamente difícil. La información está enredada en los pesos, y no hay operación limpia para quitar la contribución de una persona salvo reentrenar sin ella, o aplicar técnicas de machine unlearning que todavía están madurando y son difíciles de demostrar ante un supervisor. Un derecho que tienes que atender en días puede chocar con un modelo que reentrenas en semanas.

Ninguna de estas cosas hace equivocado el fine-tuning. Lo convierten en un compromiso cuyo coste total solo aparece más tarde, justo en el momento en que una organización regulada menos se puede permitir una sorpresa.

Coste de actualización: ¿con qué rapidez puede cambiar tu conocimiento de dominio?

Hay un tercer eje práctico, y es el que muerde operativamente y no jurídicamente: ¿cuánto cuesta cambiar lo que el modelo sabe?

El conocimiento de dominio en un negocio regulado no es estático. Se revisa una política, se mueve un umbral, se sustituye una regla. Cómo absorbe cada enfoque ese cambio difiere en órdenes de magnitud. Actualizar un corpus RAG es una operación documental: sustituyes la fuente, reindexas, listo, y el cambio está activo en la siguiente consulta. Actualizar un prompt es editar texto y volver a desplegar la instrucción. Actualizar conocimiento que vive en pesos afinados significa una nueva tirada de entrenamiento, revalidación y una entrega controlada de una nueva versión del modelo. Las dos primeras son horas. La tercera es un proyecto.

Aquí es donde la desactualización se vuelve un riesgo de gobernanza en lugar de una molestia. Si tu conocimiento regulado cambia más rápido de lo que puedes reentrenar, un modelo afinado que lo codifica va saliéndose del cumplimiento entre tiradas de entrenamiento, y nada en su comportamiento lo anuncia. RAG y prompt mantienen el contenido regulado de cambio rápido en una capa que puedes actualizar a la velocidad a la que las reglas cambian de verdad.

Un marco de decisión para un equipo regulado

Nada de esto se reduce a "usa siempre RAG". Se reduce a hacer corresponder la técnica con lo que son los datos y cómo se comportan.

El marco que aguanta ante un comité de riesgos es separar dos cosas que el modelo necesita. Necesita habilidades, la competencia estable y general de leer un documento, seguir un formato, razonar en una tarea estructurada. Y necesita hechos, el contenido concreto, cambiante y a menudo regulado sobre el que razona. Pon las dos en sitios distintos.

El fine-tuning es defendible para enseñar habilidades duraderas y no sensibles: un estilo de casa, un esquema de salida, un patrón de razonamiento que no cambia y no lleva datos personales. Es un mal sitio para poner hechos, y un sitio peligroso para poner hechos regulados, precisamente por la auditabilidad, el borrado y el coste de actualización. Los hechos regulados pertenecen a RAG, donde se mantienen inspeccionables, borrables y actuales, bajo control de acceso aplicado en el momento de la recuperación. Y el prompt lleva el contexto transitorio de cada llamada, que ni persiste ni necesita hacerlo. La mayoría de los sistemas regulados robustos usa las tres deliberadamente, con una regla clara sobre qué tipo de información puede vivir dónde, en lugar de echar mano de la que pareció más precisa en una demo.

Así que la pregunta que resolver antes de elegir una técnica no es "¿qué enfoque hace al modelo más preciso?". Es qué datos regulados nos llevaría a almacenar este enfoque, dónde vivirían, y podemos auditarlos, borrarlos y actualizarlos a la velocidad que exigen nuestras obligaciones. Responde primero a eso, y la precisión pasa a ser una elección que haces dentro de un diseño seguro en lugar de la razón por la que acabaste en uno inseguro.

Si quieres mapear qué parte de tu conocimiento de dominio pertenece a los pesos, a la recuperación o al prompt, reserva una reunión y tráenos el proceso con más datos regulados.