Empezar por la tarea, no por una clasificación de modelos
Describa el trabajo concreto que debe apoyar el modelo: encontrar respuestas en normas internas, sugerir una clasificación de correo, resumir un documento o redactar un primer borrador. Para cada tarea indique usuario, sensibilidad de entradas, salida esperada y decisión posterior de una persona. Un modelo que destaca en pruebas públicas puede fallar con sus idiomas, terminología y excepciones. Defina cuándo debe abstenerse o pasar el trabajo a una persona. Primero pregunte si hace falta un modelo: una búsqueda, reglas deterministas o una plantilla pueden ser más precisas y baratas. Nombre el proceso actual contra el que medirá la mejora.
Privado puede significar ejecutar en su servidor, utilizar una instancia dedicada del proveedor o una aplicación bajo condiciones restrictivas de tratamiento de datos. Aclare qué requisito importa. Puede ser ubicación de datos, prohibición de entrenar con contenido, control de accesos o funcionamiento sin red externa. Documente las amenazas que desea reducir y las que permanecerán. Un modelo local todavía puede revelar información a un usuario con permisos demasiado amplios. La decisión de alojamiento sigue al flujo de datos y las responsabilidades, no solo a la dirección del servidor. Alinee a responsables legales, de seguridad y producto sobre el significado de privado antes de comparar precios.
Crear pruebas a partir del trabajo real
Reúna preguntas y documentos representativos con permiso de sus dueños. Incluya casos habituales, difíciles y ambiguos, varios idiomas y situaciones donde la respuesta correcta es que no se dispone de la información. Defina expectativas de referencia y puntuación antes de probar. En extracción se puede comprobar cada campo; las respuestas sobre una base documental necesitan sustento factual, integridad y citas útiles. Use revisión humana con criterios claros y varios evaluadores para casos críticos. Un resultado medio puede ocultar una debilidad peligrosa en un grupo pequeño pero importante. Registre el tipo de cada fallo para saber qué corregir.
Separe ejemplos de desarrollo de otro conjunto independiente de control. Ajustar constantemente sobre la misma prueba crea un resultado que puede no repetirse en el trabajo normal. Registre tamaño, origen, fecha y limitaciones de cada conjunto. Añada errores nuevos del piloto sin perder una base estable para comparar versiones. El perfil NIST para IA generativa subraya gestionar riesgos durante todo el ciclo de vida; un benchmark aislado no sustituye la observación continua. Establezca un límite aceptable de error y quién lo aprueba. Proteja los datos de prueba, pues pueden ser tan sensibles como los documentos de producción.
Comparar calidad con la alternativa más sencilla
Pruebe candidatos con los mismos datos, instrucciones y reglas de puntuación. Junto a un modelo grande incluya uno pequeño, búsqueda normal y quizá un servicio externo si las políticas lo permiten. Mire más allá de la media hacia errores capaces de llevar a una persona a una decisión equivocada. Para respuestas basadas en documentos distinga fallo de recuperación de evidencia y fallo de generación fiel. Si el modelo no reconoce la ausencia de pruebas, más entrenamiento quizá no sea la solución. Mejore antes el límite de la tarea, las instrucciones y el contexto. Conserve ejemplos buenos y malos para revisarlos con especialistas del área.
Mida cada idioma y longitud de entrada por separado. Un documento checo o español puede producir resultados distintos de uno inglés para la misma tarea. Compruebe estabilidad ante pequeñas variaciones de redacción y entre documentos parecidos. Cuente afirmaciones sin respaldo, citas erróneas, resultados incompletos y rechazos improcedentes. Para comparar costes no use solo instrucciones breves de laboratorio: el trabajo real incluye entradas largas, reintentos y revisión humana. El beneficio debe superar el proceso actual, no solo a otro modelo. Indique cuánto tiempo humano sigue siendo necesario para aceptar la salida.
Evaluar seguridad en los límites de las herramientas
Un documento de entrada puede contener instrucciones para desviar al asistente. OWASP describe prompt injection como instrucciones maliciosas dentro del contenido que anulan el comportamiento previsto. Separe reglas confiables de datos recuperados y limite las herramientas que puede llamar el modelo. No conceda toda la base de datos porque un usuario haga una pregunta. Pruebe intentos de solicitar documentos ajenos, evitar un filtro o ejecutar una acción no deseada. Exija permisos fuera del modelo: este no es una frontera de seguridad. Incluya fuentes recuperadas que parecen oficiales pero están controladas por alguien sin confianza.
Revise qué se guarda en prompts, registros, cachés y copias. Alojamiento interno no resuelve por sí solo el acceso del personal a diagnósticos ni la conservación de entradas sensibles. Defina cifrado, roles, eliminación, actualizaciones y respuesta a incidentes. Verifique licencia y procedencia de los pesos; disponibilidad pública no significa uso comercial irrestricto. Registre qué sistemas aportan contexto y adónde vuelve la salida. La aprobación de seguridad debe cubrir todo el flujo y no solo la generación. Reevalúe permisos al conectar una herramienta o fuente nueva al asistente.
Medir hardware y latencia con su carga real
El rendimiento depende del tamaño del modelo, longitud del contexto, demanda simultánea, hardware y forma de servirlo. Mida tiempo hasta primera respuesta, tiempo completo, memoria y comportamiento en picos. En una tarea en vivo de un operador, la lentitud puede forzar un rodeo manual; para un resumen nocturno puede importar más terminar de manera previsible. MLPerf ofrece benchmarks de inferencia definidos públicamente, pero la inversión necesita probar su tarea y configuración. Un número técnico sin carga descrita no se puede trasladar. Incluya el documento real más largo y cuántas personas pueden preguntar a la vez.
Cuente más que comprar o alquilar GPU: capacidad de reserva, actualizaciones, supervisión, copias, energía, gestión de accesos y tiempo del personal. Compare el coste por resultado aceptado, no solo por millón de tokens. Un modelo que requiere corrección humana frecuente puede ser más caro aun siendo barato de ejecutar. Decida si la demanda exige realmente un servidor dedicado todo el día. Un piloto puede revelar que procesar por lotes o utilizar un modelo pequeño cumple el objetivo con infraestructura más simple. Registre supuestos de volumen y concurrencia para recalcular el coste. Considere también mantener la aplicación alrededor del modelo.
Hacer que el piloto demuestre rechazo y escalada
Limite el primer piloto a una tarea y un grupo reducido. Fije antes cantidad de casos, medidas de calidad, tiempo máximo, coste y condiciones de parada. Pruebe solicitudes habituales, un documento sin respuesta, fuentes contradictorias y contenido malicioso intencionado. Los usuarios deben saber cuándo leen un borrador y quién responde de la decisión final. Conserve evaluaciones de fallos sin copiar innecesariamente datos sensibles. Después separe errores del modelo de problemas en datos, recuperación o redacción de la tarea. Cada causa requiere corrección distinta. Permita a los revisores marcar una salida insegura o sin respaldo.
Compare el piloto con el método anterior. Mida tiempo humano, correcciones y calidad del resultado. Trabajar más rápido sin corrección aceptable no es éxito; una gran corrección con coste inasumible tampoco. Pregunte a los usuarios cuándo ignoraron la respuesta. Un piloto fallido aporta valor si muestra que debe estrecharse la tarea o resolverse de otra manera. Documente la decisión siguiente con pruebas e incertidumbre, no con impresiones de demostraciones vistosas. Decida si otra prueba puede responder lo pendiente antes de comprometerse a alojar el sistema permanentemente.
Gestionar cambios del modelo como cambios del producto
Un archivo de pesos, prompt, proceso de recuperación o índice nuevo puede modificar el comportamiento sin cambiar la pantalla. Versione estas piezas y ejecute el conjunto de control antes de publicar. Si cae la calidad, debe poder restaurar la configuración anterior e identificar qué versión produjo una salida. Supervise errores, abstenciones, latencia y tipos de preguntas sin invadir la privacidad. Revise periódicamente resultados anonimizados de forma segura con especialistas. Se trata de un sistema en operación con responsabilidades, no de instalar un modelo una vez. Asigne dueño al lanzamiento y registre cómo se aprueba o rechaza un cambio.
Nombre responsables de fuentes de datos, modelo, infraestructura y soporte. Cuando cambia una norma interna, alguien debe actualizarla y verificar que la respuesta antigua ya no se ofrece. Prepare respuesta ante una salida perjudicial: corrección, aviso a afectados y quizá suspensión temporal. Decida dónde es obligatoria la aprobación humana y dónde basta revisar muestras. Debe poder apagarse la herramienta sin destruir documentos originales ni procesos de trabajo. Revise costes y calidad al crecer el uso; la economía del piloto quizá no represente un despliegue para toda la empresa.
Lista para decidir la operación
Antes de invertir confirme tarea, flujo de datos, permisos, conjunto de evaluación, referencia, objetivos y responsables. Mida rendimiento en el hardware objetivo con entradas realistas. Pruebe instrucciones hostiles en documentos, ausencia de respuesta, pérdida de disponibilidad y vuelta al proceso previo. Verifique licencias del modelo y de las fuentes. Prepare un modelo de costes para mayor volumen. Si afecta decisiones sobre personas o dinero, defina el límite de revisión humana. Sin estos elementos, pedir IA privada resulta demasiado impreciso para comparar soluciones o aprobar producción.
EXCOIN puede preparar el piloto y diseño operativo, pero no prometer calidad o coste de un modelo sin medirlo con sus datos. Lo mejor puede ser un modelo pequeño, búsqueda sin generación, servicio externo con condiciones contractuales adecuadas o aplazar el proyecto. Un despliegue privado tiene sentido si aporta control o economía demostrables y un equipo puede mantener todo el flujo con seguridad. Decida según resultados aceptados, coste y riesgo, no por el nombre del modelo. Conserve el registro de decisión para poder cambiarlo cuando aparezcan nuevas pruebas.