Introducción: el objetivo de un RFP centrado en el uso

Redactar un RFP para un avatar IA de recepción exige equilibrar requisitos técnicos, limitaciones operativas, obligaciones legales y criterios objetivos de evaluación. El documento debe permitir que proveedores diversos respondan de forma comparable y que el cliente clasifique las respuestas sin ambigüedad.

Esta guía propone una checklist estructurada, modelos de cláusulas contractuales y SLA, un cuadro de evaluación ponderado y un mapeo para verificar diferenciadores técnicos habituales (RAG, multi‑LLM, integraciones, formatos documentales, compatibilidad hardware, accesibilidad, soporte 24/7).

Por qué estructurar el RFP desde el inicio

Un RFP estructurado reduce el riesgo de comparaciones incompletas, evita omisiones en temas sensibles (protección de datos, accesibilidad, continuidad) y aclara las interfaces esperadas con los sistemas de negocio. También facilita la fase de negociación contractual al listar previamente las obligaciones técnicas y operativas.

El objetivo operativo es sencillo: obtener respuestas homogéneas, medibles y verificables para seleccionar, sobre criterios documentados, el proveedor más adecuado al contexto de despliegue (sitios, públicos, restricciones regulatorias).

Checklist RFP estructurada – apartados obligatorios

Incluir las siguientes secciones como requisitos mínimos: objeto del contrato, alcance de los sitios, descripción de los casos de uso prioritarios, restricciones de accesibilidad, expectativas sobre idiomas, formatos de interacción (vocal, táctil) y modos de explotación previstos.

Especificar los elementos técnicos indispensables: compatibilidad de pantallas/terminales con familias de sistemas (Tizen, Android, Windows) según la infraestructura existente, limitaciones de red y seguridad, capacidades de despliegue multisede y modalidades de actualización centralizada de la base de conocimiento.

  • Objeto y alcance del proyecto

  • Casos de uso prioritarios y exclusiones

  • Restricciones de accesibilidad (modos vocales, subtítulos, lengua de signos (LSF), táctil)

  • Idiomas soportados y capacidad multilingüe

  • Compatibilidad hardware y familias de SO (Tizen, Android, Windows) - indicar el existente

  • Arquitectura objetivo y requisitos de red/seguridad

Checklist RFP – apartados operativos y de gobernanza

Solicitar precisiones sobre la gobernanza del contenido: quién edita la base de conocimiento, proceso de validación de las respuestas de negocio, herramientas de actualización y nivel de granularidad de los derechos de edición.

Especificar las expectativas de explotación: procedimientos de mantenimiento, disponibilidad esperada (servicio posible 24/7), modalidades de soporte, formación de equipos y recuperación ante incidentes. Indicar también los entregables esperados para la fase piloto y el paso a producción.

  • Modelo de gobernanza y roles (editor, validador, administrador)

  • Proceso de actualización de contenidos de negocio

  • Plan de despliegue piloto y criterios de aceptación

  • Modalidades de formación y documentación

  • Soporte operativo y modalidades de guardia 24/7

Apartados jurídicos y seguridad de datos a solicitar

Exigir una descripción clara de los tratamientos de datos, el alcance de los datos recogidos y las medidas de seguridad implementadas. Pedir información sobre el alojamiento de los datos y la posibilidad de un despliegue en infraestructura dedicada si fuera necesario.

Especificar las exigencias jurídicas a integrar en el contrato: responsabilidad, propiedad intelectual de prompts/persona, confidencialidad, condiciones de copia de seguridad y restauración, condiciones de fin de contrato y recuperación de datos. Formular estas cláusulas como criterios de elegibilidad en lugar de simples opciones.

  • Descripción de los tratamientos y finalidades

  • Localización del alojamiento y opciones de infraestructura

  • Medidas de seguridad técnicas y organizativas

  • Propiedad de contenidos y adaptaciones de la persona

  • Modalidades de restitución o eliminación de datos al finalizar el contrato

Modelos de cláusulas contractuales y estructura SLA (a personalizar)

Proporcionar modelos de cláusulas facilita la comparación. Estos son los elementos esenciales que el RFP debe proponer al proveedor para respuesta: garantía de disponibilidad, niveles de soporte, mantenimiento programado, recuperación tras incidente, confidencialidad y auditorías. Indicar claramente que los elementos cuantificados serán negociados e insertados en el contrato final.

Ejemplo de estructura SLA a incluir en el RFP: definición de niveles de gravedad, compromiso de respuesta inicial por gravedad, compromiso de resolución, modalidades de notificación y escalado, mantenimiento planificado e informes. Especificar también la necesidad de una organización de soporte capaz de operar 24/7 si el servicio está expuesto de forma continua.

  • Definiciones: disponibilidad, interrupción programada, incidente crítico

  • Niveles de gravedad y respuestas esperadas (respuesta inicial, resolución)

  • Modalidades de notificación y escalado

  • Mantenimiento planificado y ventanas de trabajo

  • Informes periódicos y revisión del servicio

Cuadro de evaluación ponderado y ejemplo de scoring (ejemplo ilustrativo)

Un cuadro de evaluación ayuda a comparar las ofertas objetivamente. Presentar los criterios principales (técnico, seguridad, accesibilidad, integraciones, gobernanza, coste total) y explicar la ponderación interna adoptada. Es importante adaptar la ponderación al contexto de negocio y las prioridades del proyecto.

Ejemplo ilustrativo: ponderar más la parte técnica e integraciones si el proyecto implica conexiones a sistemas de negocio, o priorizar la accesibilidad si el público es mayoritariamente vulnerable. Lo siguiente es un ejemplo ilustrativo y debe adaptarse a la necesidad.

  • Criterios técnicos: arquitectura, soporte multi‑LLM, RAG, formatos documentales

  • Seguridad y cumplimiento: medidas técnicas, alojamiento, auditorías

  • Accesibilidad: modos vocal/táctil, subtítulos, soporte LSF

  • Operativo: gobernanza, formación, soporte 24/7

  • Coste y modelo económico: licencias, costes de integración, mantenimiento

Mapeo práctico para verificar diferenciadores técnicos

Para verificar las afirmaciones técnicas de los proveedores, solicitar pruebas reproducibles: demostración en casos reales, acceso a un entorno de prueba para validar la calidad de las respuestas RAG, pruebas multilingües y escenarios de integración con APIs ficticias o sandbox.

Pedir a cada proveedor que detalle el formato y los volúmenes documentales aceptados para la ingestión, la gestión de versiones y los motores LLM compatibles u orquestables. Verificar la compatibilidad prevista con las familias de pantallas/terminales (Tizen, Android, Windows) y la capacidad de funcionar en modo vocal, táctil o híbrido según las configuraciones.

  • Pruebas solicitadas: demostración, entorno sandbox, casos de prueba de negocio

  • Formatos documentales para RAG (PDF, DOCX, XLSX, TXT, CSV, NDJSON) - solicitar precisiones

  • Soporte multi‑LLM y estrategia de orquestación

  • Compatibilidad hardware y modalidades de despliegue multisede

  • Pruebas de accesibilidad y evidencias de validación con usuarios

Puntos de vigilancia operativa y errores frecuentes a evitar

No descuidar la gobernanza de contenidos: dejar la responsabilidad de las respuestas únicamente en el proveedor sin definir un proceso interno de validación suele conducir a desviaciones de calidad. Precisar quién es responsable de la actualización de la información de negocio.

Evitar omitir la fase piloto. Un piloto permite validar las integraciones, la calidad de las respuestas, la ergonomía de interacción vocal y táctil y la aceptación por parte de los usuarios. Asimismo, aclarar desde el RFP el alcance de las pruebas aceptadas para la aceptación final.

  • Definir explícitamente la gobernanza de contenidos

  • Prever escenarios de prueba representativos y un piloto formalizado

  • Verificar la capacidad del proveedor para proporcionar un entorno de prueba

  • No confundir disponibilidad prometida y modalidades de guardia operativa

En la práctica: preguntas para formular a los proveedores en las entrevistas

Para completar el expediente escrito, preparar un conjunto de preguntas sobre los puntos sensibles: cómo el proveedor maneja la confidencialidad de los datos, qué garantías hay sobre copias de seguridad y restauraciones, cómo se realizan las pruebas multilingües y qué herramientas de back‑office se facilitan para editar la base de conocimiento.

Solicitar también demostraciones focalizadas sobre la gestión de interrupciones, la actualización masiva de contenidos y la capacidad de personalizar persona y voz según las restricciones de derechos e imagen. Estos elementos permiten juzgar la madurez operativa más allá de las respuestas escritas.

  • Ejemplos de preguntas: gestión de incidentes, recuperación, localización de datos

  • Escenarios de demostración a solicitar: importación de documentos, consulta RAG, prueba vocal multilingüe

  • Evaluar la ergonomía del back‑office de edición

Conclusión: formalizar para reducir el riesgo y facilitar la elección

Un RFP completo y estructurado permite comparar proveedores sobre bases objetivas y reduce los riesgos ligados a la seguridad, accesibilidad y explotación. Al estructurar los apartados obligatorios, proponer modelos de cláusulas y un cuadro de evaluación, se facilita una toma de decisión documentada.

SANIA puede ilustrar algunos de los diferenciadores operativos mencionados aquí: avatar IA de recepción diseñado para pantalla o terminal interactivo, disponible 24/7 y capaz de comunicarse en múltiples idiomas. Para estudiar la adecuación de este enfoque a su contexto y recibir un ejemplo de RFP personalizable, puede solicitar una demostración y un kit RFP adaptado.