Pegar un PDF interno en ChatGPT es rápido. El documento sale del perímetro. El modelo no tiene vuestra identidad. No hay fuente que el compañero pueda abrir. Mañana no queda un sistema. Es un hábito, no un montaje.
Qué falla cuando se pega
- Perímetro. El archivo pasa a un servicio público. Aunque «no entrenéis con mis datos», sigue siendo un envío que nadie diseñó.
- Quién ve qué. Quien tiene el PDF lo pega. Quien no debería verlo no tiene voto. El modelo no hereda el ACL de Drive o de la wiki.
- Fuente. La respuesta no enlaza al procedimiento vigente. Al día siguiente nadie sabe qué versión se usó.
- Operación. No hay índice. No hay reindexado. No hay registro de preguntas. Cada persona repite el copiar y pegar.
Lo mismo vale para Custom GPTs con documentos subidos a una cuenta personal. Sigue siendo el archivo en un producto que no es vuestro entorno.
Qué montar en su lugar
Un RAG o un GPT vuestro. Los documentos viven donde vosotros decís. La respuesta cita. El chat o la API usa cuentas de empresa. Alguien puede reindexar. Eso está en montar un RAG interno y en datos y acceso para un GPT privado.
El caso no sustituye todos los PDFs del histórico. Sustituye el hábito en un caso: «este tipo de pregunta ya no se pega; se pregunta al sistema». El documento sigue en la wiki o en Drive. El modelo solo ve lo indexado.
Cómo salir del hábito
- Nombrar el caso (un equipo, un tipo de documento).
- Dejar de pegar ese tipo de archivo en chats públicos.
- Poner el chat o la API donde ya trabajan. Si hay que abrir otra web olvidada, volverán al pegado.
- Cuando la respuesta falle, se corrige el documento de origen y se reindexa. No se «enseña» al chat con más PDFs sueltos.
OpenAI puede ser el modelo. LangChain, Python y FastAPI, el cableado. El PDF se queda donde está. Madrid. RAG y agentes.