Una ingeniería técnica prescribió hace tres años un GMAO+GIS a un operador industrial privado. La elección fue defendible en el momento: la plataforma tenía API pública, documentación OpenAPI 3.0 publicada y formato de exportación declarado en la ficha comercial. Tres años después, el operador forma parte de un grupo corporativo que decide consolidar la operación en una plataforma distinta. El operador pide a la ingeniería, en el marco del proyecto todavía vivo, soporte para la migración. La primera semana revela lo que la ficha comercial no decía: el endpoint de exportación bulk existe, pero devuelve cada entidad en un JSON propietario paginado que pierde las relaciones entre activos, órdenes de trabajo, contratos y arrendatarios; el mapa de campos hacia formatos OGC es interpretación de cada integrador; la exportación completa del histórico exige mil doscientas llamadas paginadas. Lo que iba a ser una migración de tres meses se convierte en un proyecto de dieciocho, y la conversación con el operador cambia de tono.

La escena no es imputable al fabricante del GMAO, ni siquiera a la ingeniería que lo prescribió. Es imputable a la falta de un criterio contractual explícito en el momento de la prescripción. En un mercado de SaaS técnico donde la promesa de "API abierta" se ha convertido en línea base comercial, la cláusula de salida es lo que la ingeniería no pactó con el suficiente detalle. Esa cláusula es hoy un criterio técnico de prescripción, no un extra jurídico que se cierra en la última página del contrato.

Qué significa realmente "API abierta"

OpenAPI 3.0 es un estándar de documentación, no una garantía de portabilidad de datos. Un fabricante puede publicar una especificación OpenAPI impecable y exponer únicamente endpoints operativos: crear una orden de trabajo, actualizar un estado, consultar un activo. La ruta de exportación masiva —capacidad de sacar todo el maestro de activos, todo el histórico de intervenciones, toda la cartografía georreferenciada— es una promesa distinta que rara vez viene detallada en la ficha comercial. La ingeniería que verifica solo la existencia de la OpenAPI cumple con la revisión formal y se queda sin la revisión útil.

La segunda ambigüedad es la del formato. Un endpoint que devuelve JSON no es equivalente a un endpoint que devuelve GeoPackage, GeoJSON o Shapefile con el esquema de campos documentado. Un fabricante puede afirmar "exportación en formatos estándar" refiriéndose a JSON, XML y CSV, y ninguno de los tres transporta topología GIS sin conversión adicional. Cuando llega el momento de migrar, la conversión es el proyecto oculto que nadie estimó y que la ingeniería termina absorbiendo en horas no facturables.

Las cuatro cláusulas que la prescripción debería fijar

La responsabilidad de una ingeniería que prescribe una plataforma técnica de larga duración no termina en la elección: incluye la definición de las condiciones bajo las cuales el cliente podrá salir de esa plataforma sin dependencia técnica. Cuatro cláusulas resuelven la mayor parte de los casos y deberían formar parte del pliego técnico o del anexo contractual.

La primera es la exportación masiva en formatos OGC. Para datos espaciales, el fabricante entrega el maestro de activos en GeoPackage o Shapefile con esquema de atributos documentado. Para datos operativos, un formato normalizado que preserve las relaciones —típicamente un dump SQL o CSV multi-tabla— con el esquema publicado. La segunda es la exportación del histórico completo. No una ventana de doce meses: todo el histórico desde el arranque, con marcas de tiempo originales y trazabilidad de usuario. La tercera es un SLA sobre la duración del proceso de exportación completa para una cartera de referencia; sin ese SLA, la exportación se convierte en un proyecto abierto de duración indefinida. La cuarta es una cláusula de escrow de datos: qué ocurre si el fabricante cesa actividad, si es adquirido por un competidor directo del cliente, o si eleva unilateralmente las condiciones comerciales por encima de un umbral acordado.

La verificación práctica antes de firmar

Las cláusulas contractuales solo tienen valor si se verifican en vivo antes de firmar. La verificación es sencilla y consiste en tres pruebas. La primera es la demostración de la exportación masiva contra un conjunto de datos representativo del proyecto —al menos mil activos con topología, órdenes y adjuntos—, no contra el dataset de demo del comercial. La segunda es la lectura del fichero exportado por una segunda plataforma o herramienta libre para comprobar que el esquema es realmente autodescrito y no requiere documentación interna del fabricante. La tercera es la medición del tiempo total del proceso, del click a la disponibilidad completa del fichero descargable. Si cualquiera de las tres pruebas falla, la plataforma no cumple con el criterio, independientemente de lo que diga la ficha comercial. El coste operativo de estas tres pruebas para la ingeniería prescriptora es de una jornada por candidato, coste que se recupera con creces la primera vez que evita una migración que se hubiera vuelto proyecto. La ausencia de esta verificación es la que produce los dieciocho meses de migración tres años después.

En Maptainer publicamos la URL de la especificación OpenAPI y el flujo de exportación completo desde la web pública, precisamente para que la prescripción no dependa de la palabra del comercial sino de la verificación técnica del prescriptor. La comparación entre plataformas se hace con los mismos criterios sobre la misma clase de dataset; el mercado ha alcanzado un nivel de madurez donde eso es exigible por parte de una ingeniería seria.

La responsabilidad extendida del prescriptor

La ingeniería que prescribe una plataforma técnica de larga duración prescribe un modelo operativo cuyo horizonte de vida supera el del proyecto en el que la incorpora. Cuando ese modelo tropieza con una migración cinco años después, la ingeniería que lo prescribió sigue apareciendo en la conversación aunque no siga vinculada al cliente. El criterio profesional que hoy separa una prescripción defendible de una prescripción vulnerable no está en la funcionalidad de la plataforma —el mercado ha convergido en funcionalidad— sino en la robustez de la cláusula de salida. Esa cláusula es la frontera de la responsabilidad técnica ampliada: la línea a partir de la cual el prescriptor asume que su elección no atrapará al cliente cuando el contexto cambie. Las ingenierías que adoptan esta disciplina reformulan la conversación con sus clientes desde "qué plataforma es más potente" hacia "qué plataforma nos deja seguir siendo dueños del dato dentro de tres años". La segunda pregunta es la que el cliente quiere realmente contestar, aunque no siempre sepa formularla.