En este artículo
Un proveedor puede entregar una demostración convincente y, aun así, convertirse en una fuente de dependencia, retrabajo o riesgo operativo. Evaluar proveedores tecnológicos exige mirar más allá de la propuesta comercial: implica determinar si su forma de trabajar puede sostener una plataforma crítica, integrarse con el ecosistema existente y responder cuando la operación no admite interrupciones.
Para una entidad pública, una universidad o una empresa con canales digitales consolidados, la decisión no se reduce a comprar desarrollo, inteligencia artificial o soporte. Se está eligiendo la capacidad de evolucionar procesos, datos y experiencias de usuario sin comprometer seguridad, gobernanza ni continuidad operativa.
Evaluar proveedores tecnológicos desde el contexto
El primer error es comparar proveedores con una lista genérica de funcionalidades. Dos organizaciones pueden requerir un portal Drupal, automatización con agentes de inteligencia artificial o una migración de contenidos, pero el nivel de exigencia cambia por completo según sus integraciones, obligaciones regulatorias, volumen de usuarios, modelo editorial y capacidades internas.
Antes de abrir una convocatoria o solicitar cotizaciones, conviene formular el problema con precisión. No basta con decir que el sitio está desactualizado o que se necesita incorporar IA. Es necesario establecer qué procesos están afectados, qué riesgos deben reducirse, qué sistemas no pueden fallar y cuáles son los resultados verificables esperados. Por ejemplo, una modernización de Drupal puede requerir mejorar la administración editorial y la accesibilidad, pero también conservar URLs, integrar autenticación institucional, mantener trazabilidad y cumplir lineamientos GOV.CO.
Este ejercicio evita evaluar una promesa abstracta de innovación. Permite valorar si el proveedor entiende las restricciones que hacen viable la solución y si propone una arquitectura proporcional al problema, no una herramienta de moda aplicada sin criterio.
La experiencia debe ser verificable y comparable
La experiencia relevante no equivale a una larga lista de clientes ni a una colección de capturas de pantalla. Un proveedor confiable puede explicar qué problema resolvió, qué decisiones técnicas tomó, qué restricciones enfrentó y cómo mantuvo la solución después de la salida a producción.
En proyectos de alta responsabilidad, pida evidencia sobre situaciones similares: migraciones desde plataformas heredadas, integraciones con sistemas empresariales, implementación de flujos editoriales, cumplimiento de accesibilidad, gestión de picos de tráfico o recuperación ante incidentes. La similitud no tiene que ser sectorial en todos los casos. Una empresa puede no haber trabajado con su misma institución, pero debe demostrar experiencia en complejidad equivalente.
También importa identificar quién realizará el trabajo. Una propuesta sólida puede depender de perfiles que no estarán asignados al proyecto. Solicite conocer la estructura del equipo, sus roles, la dedicación prevista y el mecanismo para reemplazar conocimiento crítico. La capacidad institucional se demuestra cuando el servicio no queda sujeto a una sola persona o a una disponibilidad incierta.
Preguntas que revelan madurez técnica
Las mejores preguntas no buscan una respuesta correcta de memoria. Buscan entender el razonamiento del proveedor. Pregunte cómo abordaría una integración con un sistema que no puede modificarse, cómo validaría una migración con millones de registros o qué controles aplicaría antes de permitir que un agente de IA ejecute acciones sobre sistemas internos.
Un proveedor maduro explicará supuestos, dependencias, límites y alternativas. Si responde que todo es posible sin pedir información adicional, probablemente está subestimando el alcance. Si solo enumera tecnologías, tampoco está hablando de la operación que deberá sostenerse después.
Arquitectura, seguridad y mantenibilidad no son anexos
La calidad técnica no se puede inferir de la interfaz. Una plataforma bien diseñada debe poder evolucionar sin que cada ajuste implique intervenir múltiples sistemas, duplicar datos o depender de código difícil de mantener. Por ello, la evaluación debe incluir criterios de arquitectura empresarial desde el inicio.
Revise cómo el proveedor define responsabilidades entre componentes, administra integraciones, documenta APIs, gestiona ambientes y controla cambios. En una arquitectura headless, por ejemplo, separar frontend y CMS puede mejorar flexibilidad y rendimiento, pero introduce necesidades adicionales de observabilidad, despliegue, seguridad y coordinación editorial. No siempre es la opción correcta. Depende del equipo disponible, de la frecuencia de cambios y de los objetivos del canal.
La seguridad requiere el mismo nivel de especificidad. No basta con afirmar que se siguen buenas prácticas. El proveedor debe describir cómo administra accesos, secretos y vulnerabilidades; cómo protege datos personales; cómo realiza pruebas; y qué proceso activa ante un incidente. Para entidades sujetas a regulación o a lineamientos públicos, estas prácticas deben quedar documentadas y ser auditables.
En soluciones con inteligencia artificial, la evaluación incorpora preguntas adicionales. Es necesario conocer qué información llegará al modelo, dónde se procesa, cómo se limitan las respuestas y qué mecanismos impiden acciones no autorizadas. Un agente conectado a sistemas institucionales no debe operar con permisos amplios ni decisiones opacas. Debe ejecutar acciones acotadas, auditables y medibles, con controles humanos cuando el impacto lo exija.
Evalúe el método de ejecución, no solo el entregable
Los retrasos y sobrecostos rara vez se originan únicamente en una mala estimación. Con frecuencia aparecen porque el proveedor no cuenta con un método para descubrir dependencias, validar decisiones y gestionar cambios. La propuesta debe mostrar cómo se pasa del diagnóstico a la construcción, de las pruebas a la puesta en producción y de la entrega al soporte.
Un enfoque responsable suele incluir levantamiento técnico y funcional, priorización de riesgos, definición de arquitectura, diseño de experiencia, construcción iterativa, pruebas y transferencia de conocimiento. La secuencia puede variar, pero no debería ocultar fases críticas bajo términos ambiguos como “implementación integral”.
Revise especialmente los criterios de aceptación. Deben expresar comportamientos observables, niveles de servicio, requisitos de rendimiento, cobertura de pruebas y condiciones para aprobar una migración o una integración. Cuando los criterios son vagos, la organización termina validando con percepciones y no con evidencia.
La gobernanza también merece atención. Defina quién toma decisiones, con qué frecuencia se revisan avances, cómo se registran cambios de alcance y cómo se escalan bloqueos. Un proveedor que comunica riesgos temprano protege el proyecto, incluso si la conversación es incómoda. Ocultar una dependencia hasta el final no es agilidad: es falta de control.
El soporte determina el valor real de la inversión
Una plataforma crítica no termina cuando se publica. Cambian los navegadores, aparecen vulnerabilidades, evolucionan las integraciones, se actualizan los contenidos y surgen nuevas necesidades de usuarios. Por eso, evaluar proveedores tecnológicos implica entender su modelo de continuidad, no solo su capacidad de construir.
Pregunte por los acuerdos de servicio, horarios de atención, tiempos de respuesta, monitoreo, manejo de incidentes, actualizaciones y mantenimiento preventivo. También confirme qué documentación se entrega y cómo se transfiere el conocimiento al equipo interno. Un contrato de soporte útil no debe limitarse a una bolsa de horas reactiva; debe ayudar a priorizar evolución, reducir deuda técnica y mantener control sobre la plataforma.
La propiedad de los activos es otro punto decisivo. El código fuente, la documentación, las configuraciones, los componentes de diseño y los datos deben quedar bajo condiciones claras. La organización necesita poder cambiar de proveedor sin perder acceso a su operación. Evitar una dependencia excesiva no significa renunciar a una relación de largo plazo. Significa construirla sobre transparencia y capacidad de transición.
Una decisión técnica también es una decisión de gobernanza
El menor precio puede ser adecuado para una necesidad acotada, con baja criticidad y especificaciones estables. Sin embargo, en una migración de alto riesgo, una plataforma institucional o una automatización que interviene procesos sensibles, el costo inicial explica solo una parte de la decisión. Hay que considerar el costo de corregir una arquitectura deficiente, recuperar datos, responder a un incidente o rehacer una solución que nadie puede mantener.
Una matriz de evaluación ayuda cuando convierte los criterios en evidencia comparable. Puede ponderar experiencia relevante, arquitectura, seguridad, metodología, equipo, soporte, transferencia de conocimiento y costo total de propiedad. La ponderación debe reflejar el riesgo real del proyecto: en un portal público, accesibilidad y operación editorial pueden ser determinantes; en una solución de IA, gobernanza de datos, trazabilidad y control de acciones pueden tener mayor peso.
La conversación final con los candidatos debe servir para validar compatibilidad de trabajo. Escuche si hacen preguntas difíciles, si distinguen entre certeza y supuesto, y si pueden explicar decisiones complejas en términos de impacto operativo. La tecnología aplicada con criterio de arquitectura y continuidad no se reconoce por una presentación llamativa, sino por la calidad de las preguntas, los controles propuestos y la responsabilidad asumida frente a la evolución futura.
Elegir bien comienza por exigir claridad. Un proveedor que ayuda a delimitar el problema, hacer visibles los riesgos y dejar capacidad instalada no solo entrega una solución: contribuye a que la organización mantenga el control de su transformación digital.