Cómo dimensionar un proyecto de preparación de datos de IA (Plantilla de RFP)

Un RFP débil obtiene respuestas débiles. Cuando las empresas emiten solicitudes de propuestas para preparación de datos de IA, los documentos frecuentemente son demasiado vagos ("Necesitamos ayuda con nuestros datos") o demasiado rígidos ("Debe soportar exactamente estas 47 características"), y ningún enfoque produce respuestas que te ayuden a tomar una buena decisión.

Un RFP fuerte describe tu situación con precisión, establece tus requisitos claramente y da a los proveedores suficiente contexto para proponer una solución realista — incluyendo decirte lo que no has considerado. Esta plantilla está diseñada para preparación de datos de IA específicamente, no para adquisición genérica de TI. Úsala como punto de partida y adáptala a tu organización.

---

Sección 1: Resumen del proyecto

Esta sección le dice al proveedor qué intentas lograr y por qué. No es una lista de requisitos — es contexto.

Qué incluir:

• Contexto organizacional: Tu industria, tamaño y entorno regulatorio relevante (sin revelar detalles sensibles)
• Estado del programa de IA: ¿Estás empezando desde cero, o tienes un pipeline de ML existente que necesita mejores datos?
• Objetivo de negocio: ¿Para qué se usarán los datos preparados? ¿Entrenamiento de modelos, fine-tuning, RAG, analítica?
• Por qué ahora: ¿Qué desencadenó este proyecto? ¿Un nuevo requisito de cumplimiento, un piloto fallido, una iniciativa estratégica de IA?

Ejemplo fuerte:

"Somos una compañía de seguros de tamaño mediano (2,000 empleados, 15 estados) preparando datos de entrenamiento para un modelo de procesamiento de reclamaciones. Tenemos 8 años de documentos históricos de reclamaciones en formatos mixtos. Nuestro piloto inicial usando datos crudos produjo una precisión de modelo inaceptable. Necesitamos un pipeline estructurado de preparación de datos para limpiar, etiquetar y formatear estos datos para fine-tuning."

Ejemplo vago a evitar:

"Estamos buscando una solución de preparación de datos de IA para apoyar nuestro viaje de transformación digital."

La versión vaga no le dice nada útil al proveedor. O declinarán responder o enviarán una propuesta genérica que no aborda tus necesidades.

---

Sección 2: Descripción de datos

La sección más importante. Los proveedores no pueden dimensionar trabajo que no entienden, y la precisión de su propuesta depende enteramente de qué tan bien describas tus datos.

Qué incluir:

• Tipos de datos: Documentos (PDF, Word, escaneos), datos estructurados (bases de datos, hojas de cálculo), imágenes, audio, video o mixtos
• Volumen: Número de registros, documentos o archivos. Tamaño total de almacenamiento. Tasa de crecimiento.
• Formato actual: ¿En qué formato están los datos hoy? Sé específico — "PDF" es mejor que "documentos," y "PDFs escaneados con capa de texto OCR" es mejor que "PDF"
• Evaluación de calidad: ¿Los datos están limpios o desordenados? ¿Hay duplicados, campos faltantes, formatos inconsistentes? Si has hecho una auditoría de datos, incluye los hallazgos.
• Sistemas fuente: ¿Dónde viven los datos? ¿Qué bases de datos, servidores de archivos o aplicaciones?
• Datos sensibles: ¿Los datos contienen PII, PHI, registros financieros o información clasificada?
• Disponibilidad de muestra: ¿Puedes proporcionar una muestra representativa a los proveedores durante la evaluación? (Esto mejora drásticamente la calidad de las propuestas.)

Ejemplo fuerte:

"Datos fuente: ~120,000 documentos de reclamaciones de seguros. 60% son PDFs tipografiados, 30% son PDFs escaneados (calidad de OCR variable), 10% son documentos de Word. Los documentos van de 1 a 50 páginas. Los datos están almacenados en una biblioteca de documentos de SharePoint y una base de datos SQL Server on-premise. Los documentos contienen PII de asegurados incluyendo nombres, direcciones, SSNs e información médica. Podemos proporcionar una muestra anonimizada de 500 documentos para evaluación."

---

Sección 3: Requisitos de cumplimiento

Establece tus requisitos de cumplimiento explícitamente. No asumas que el proveedor preguntará.

Qué incluir:

• Marcos regulatorios: HIPAA, GDPR, EU AI Act, SOC 2, ITAR, FedRAMP, regulaciones específicas de la industria
• Restricciones de manejo de datos: ¿Pueden los datos salir de tu red? ¿Pueden procesarse en la nube? ¿Hay requisitos de residencia de datos?
• Requisitos de auditoría: ¿Necesitas un rastro de auditoría completo de cada transformación de datos? ¿Informes de linaje de datos? ¿Registros de acceso?
• Requisitos de control de acceso: ¿Control de acceso basado en roles, integración SSO/LDAP, autenticación multifactor?
• Requisitos de documentación: ¿Qué documentación de cumplimiento necesitas que produzca el proveedor?

Ejemplo fuerte:

"Los datos están sujetos a HIPAA. Todo el procesamiento debe ocurrir en nuestra infraestructura — sin egreso de datos a sistemas del proveedor o entornos en la nube. Se requiere rastro de auditoría completo para cada transformación, incluyendo linaje de datos desde el documento fuente hasta el registro de entrenamiento. Control de acceso basado en roles con integración de Active Directory. El proveedor debe producir una atestación de cumplimiento HIPAA para el flujo de trabajo de preparación de datos."

Ejemplo vago a evitar:

"Debe cumplir con las regulaciones aplicables."

Esto no le dice nada al proveedor. O asumirán cumplimiento mínimo o sobredimensionarán para cubrir cada posibilidad.

---

Sección 4: Requisitos del pipeline

Describe lo que el pipeline de preparación de datos necesita hacer, no cómo debería funcionar técnicamente. Deja que el proveedor proponga la arquitectura.

Qué incluir:

• Ingestión: ¿Qué sistemas fuente necesitan conectores? ¿Qué formatos necesitan ser soportados?
• Limpieza: ¿Qué operaciones de limpieza se necesitan? ¿Deduplicación, normalización, estandarización de formatos, redacción de PII?
• Etiquetado: ¿Necesitas un flujo de etiquetado? ¿Cuántas categorías de etiquetas? ¿Tus expertos del dominio realizarán el etiquetado, o necesitas que el proveedor proporcione anotadores?
• Transformación: ¿Qué transformaciones se necesitan? ¿Extracción de texto de documentos, reconocimiento de entidades, clasificación, estructuración?
• Exportación: ¿Qué formato de salida requiere tu pipeline de ML? ¿JSONL, Parquet, COCO, esquema personalizado?
• Requisitos de calidad: ¿Qué métricas de calidad esperas? ¿Objetivos de precisión, umbrales de acuerdo entre anotadores, requisitos de completitud?

---

Sección 5: Restricciones de despliegue

Dónde y cómo debe ejecutarse la solución.

Qué incluir:

• Modelo de despliegue: ¿On-premise, nube, híbrido o air-gapped?
• Infraestructura: ¿Qué recursos de cómputo y almacenamiento están disponibles? ¿Sistema operativo, soporte de contenedores, disponibilidad de GPU?
• Red: ¿Hay acceso a internet disponible? ¿Qué restricciones de red existen?
• Integración: ¿Con qué sistemas necesita integrarse el pipeline? ¿Frameworks de ML, data warehouses, herramientas de monitoreo?
• Escalabilidad: ¿Qué volumen necesita manejar el pipeline al lanzamiento? ¿En 12 meses?

---

Sección 6: Requisitos de integración

Cómo el pipeline de preparación de datos encaja en tu stack tecnológico más amplio.

Qué incluir:

• Sistemas upstream: ¿De dónde viene la data fuente? ¿Cómo se actualiza? ¿Batch o en tiempo real?
• Sistemas downstream: ¿A dónde van los datos preparados? ¿Qué frameworks o plataformas de ML los consumirán?
• Herramientas existentes: ¿Qué herramientas de datos ya usas? ¿Se espera que el proveedor las reemplace o complemente?
• APIs: ¿Necesitas acceso API para control programático del pipeline?

---

Sección 7: Cronograma e hitos

Sé realista. Cronogramas agresivos llevan a recortar esquinas.

Qué incluir:

• Cronograma general: ¿Cuándo necesita estar operativo el pipeline?
• Hitos clave: Descubrimiento, construcción, validación, entrega — ¿qué fechas importan?
• Dependencias: ¿Qué factores externos podrían afectar el cronograma? (Aprovisionamiento de TI, disponibilidad de expertos del dominio, revisiones de cumplimiento)
• Fases: ¿Es aceptable un enfoque por fases? ¿Pipeline v1 con funcionalidad central, luego iteración?

Ejemplo fuerte:

"Pipeline operativo dentro de 8 semanas del inicio del engagement. Hitos: auditoría de datos completada para la Semana 2, pipeline de ingestión funcional para la Semana 4, flujo de etiquetado operativo para la Semana 6, pipeline completo validado y entregado para la Semana 8. Expertos del dominio disponibles 10 horas/semana durante las Semanas 3-7. El aprovisionamiento de TI se completará antes del inicio del engagement."

---

Sección 8: Criterios de evaluación

Dile a los proveedores cómo evaluarás sus propuestas. Esto moldea la calidad de las respuestas.

Qué incluir y pesos sugeridos:

• Enfoque técnico (30%): ¿La solución propuesta aborda los requisitos del pipeline? ¿Es sólida la arquitectura?
• Ajuste al modelo de despliegue (20%): ¿Funciona la solución dentro de tu infraestructura y restricciones de cumplimiento?
• Plan de implementación (20%): ¿Es realista el cronograma? ¿Son concretos los hitos? ¿Está calificado el equipo?
• Precios (15%): ¿Son transparentes los precios? ¿Está claro el costo total de propiedad, incluyendo implementación?
• Referencias (15%): ¿Ha hecho el proveedor trabajo similar en tu industria? ¿Puede proporcionar referencias?

---

Qué hace un RFP fuerte vs. débil

RFPs fuertes:

• Describen datos reales con especificidad (tipos, volúmenes, formatos, calidad)
• Establecen requisitos de cumplimiento explícitamente
• Proporcionan criterios de evaluación y pesos
• Ofrecen una muestra de datos para que los proveedores evalúen
• Incluyen cronogramas realistas con dependencias reconocidas
• Separan lo imprescindible de lo deseable

RFPs débiles:

• Describen datos vagamente o no los describen
• Listan características sin contexto de cómo se usarán
• Omiten requisitos de cumplimiento o usan lenguaje genérico
• Exigen cronogramas poco realistas sin reconocer restricciones
• No proporcionan criterios de evaluación, haciendo de las respuestas de proveedores un juego de adivinanzas
• Copian y pegan de una plantilla genérica de adquisición de TI

---

Una cosa más

Antes de emitir el RFP, considera llamar a tus dos o tres proveedores principales para una breve conversación pre-RFP. Una llamada de 15 minutos donde describas el proyecto y preguntes si son un buen ajuste ahorrará tiempo a todos. Algunos proveedores se autoexcluirán, y los que respondan proporcionarán mejores propuestas porque entendieron el contexto.

Si Ertas está en tu lista de evaluación y quieres tener esa conversación pre-RFP, agenda una llamada de descubrimiento. Te diremos honestamente si el proyecto se ajusta a nuestras capacidades — y si no, lo diremos antes de que gastes tiempo escribiendo una sección de RFP para nosotros.