Qué es Google Docs
Google Docs, o Documentos de Google, es un procesador de textos centrado en documentos compartidos. Se utiliza en el navegador y mediante aplicaciones para Android e iOS. Permite redactar, comentar, proponer cambios y exportar contenido, dentro del ecosistema de Google Drive y Workspace.
Su principal unidad de colaboración es un documento común al que acceden las personas autorizadas. Esto reduce el intercambio de copias, pero exige distinguir edición, revisión y aprobación. El último texto guardado no es necesariamente el último texto aprobado.
Para SST, puede servir como espacio de preparación de actas, guías o borradores de procedimientos. El valor reside en reunir aportaciones y resolverlas de forma ordenada. La versión de consulta debe quedar identificada y conectada con el sistema documental de la organización.
Documentación de referencia: Google Docs overview and basic functions.
De Writely a la colaboración en Workspace
Google Docs procede de Writely, el procesador web de Upstartle cuya beta apareció en agosto de 2005. En una entrevista de ese año, Sam Schillace describía un pequeño equipo que quería trasladar la edición compartida al navegador. Google anunció la incorporación de Writely el 9 de marzo de 2006.
El 10 de octubre de 2006 se presentó Google Docs & Spreadsheets, reuniendo documentos y hojas en un acceso común. La salida de la fase beta se anunció el 7 de julio de 2009. En marzo de 2010 Google adquirió DocVerse, relacionado con colaboración sobre Microsoft Office.
En abril de 2010 Google presentó un editor reconstruido con mejoras de maquetación, importación y edición en tiempo real. El recorrido muestra una tensión constante: mantener facilidad de colaboración y ampliar capacidades documentales. Las pestañas anunciadas en octubre de 2024 añadieron otra forma de organizar documentos extensos.
La ficha diferencia esos hitos de las funciones actuales. Una ayuda antigua puede describir una interfaz o una función histórica; antes de replicar un flujo, comprobar su disponibilidad en la cuenta y el dispositivo utilizados.
Documentación de referencia: Google welcomes Writely, March 2006 · Writely creator interview, October 2005 · New Beginnings: Google Docs and Spreadsheets, October 2006 · Google Apps leaves beta, July 2009 · Google acquires DocVerse, March 2010 · Rebuilt real-time editor, April 2010 · Document tabs announced in October 2024.
Pestañas, apartados y navegación
Las pestañas y subpestañas permiten separar bloques dentro de un documento. La documentación actual fija un máximo de 100 pestañas. Al descargar o imprimir se elige la pestaña actual o todas; la descarga predeterminada puede limitarse a la actual.
Para un dossier de una campaña preventiva, una estructura posible es objetivo, materiales, coordinación y evaluación. Cada bloque debería tener una finalidad clara y referencias a la documentación aprobada. Evitar repetir la misma instrucción en varias pestañas, porque una modificación puede dejar versiones divergentes.
Antes de entregar una copia, comprobar que incluye todos los apartados previstos. Una exportación visualmente correcta puede estar incompleta si solo contiene la pestaña activa. Utilizar un índice de comprobación independiente ayuda a detectar esa omisión.
Documentación de referencia: Use document tabs and export all tabs.
Formato con páginas y sin páginas
El modo con páginas admite encabezados, pies y números de página. El modo sin páginas utiliza desplazamiento continuo y adapta el texto al ancho disponible; permite tablas anchas. Algunos elementos de página dejan de mostrarse al cambiar al modo continuo.
Elegir el formato según la consulta. Un borrador colaborativo puede beneficiarse de lectura continua, mientras un informe para impresión necesita comprobar paginación y referencias. No utilizar números de página como única forma de localizar una instrucción si el documento se leerá en distintos formatos.
En una guía multilingüe, el texto puede ocupar extensiones diferentes. Revisar cada idioma en su formato final para evitar títulos aislados, tablas cortadas o pies incompletos. La revisión debe abarcar la copia descargada además de la vista en línea.
Documentación de referencia: Pages and pageless document setup.
Permisos y participación de lectores y revisores
Los permisos distinguen lectura, comentario y edición. Una persona con permiso para comentar puede proponer cambios sin editar directamente el texto aceptado. La configuración de acceso determina la audiencia efectiva del documento y puede estar condicionada por la organización.
Para preparar un acta, asignar edición a quien consolida, comentario a quien revisa y lectura a quien consulta el resultado. Son decisiones de organización propuestas, no una obligación del producto. Un enlace cómodo debe seguir conduciendo a una versión y una audiencia conocidas.
Probar el acceso con una cuenta del rol previsto, incluida una externa cuando corresponda. Revisar qué sucede al retirar permisos y quién mantiene el documento si cambia su propietario. Una mención o una invitación pendiente no demuestra acceso efectivo.
Documentación de referencia: Document sharing basics · Suggest edits in Google Docs.
Sugerencias e historial de versiones
Las sugerencias se aceptan o rechazan; el historial permite recuperar estados anteriores y nombrar hitos. Actualmente, Google también documenta eliminación permanente de historial para cuentas personales. Por tanto, el historial de edición no debe tratarse como un archivo inmutable.
Un nombre como «revisión técnica» debe corresponder a una decisión documentada. Conviene acompañarlo de responsable, alcance y fecha. Si dos revisores discrepan sobre un acuerdo, conservar la cuestión para resolverla; la edición más reciente no determina quién tiene razón.
Antes de restaurar un estado anterior, entender qué trabajo posterior se podría perder de la versión activa. Para comparar, puede resultar más adecuado crear una copia. El proceso de conservación debe identificar qué evidencia se guarda fuera de la edición cotidiana.
Documentación de referencia: Suggest edits in Google Docs · Version history, named versions and access.
Office, exportación y Markdown
Docs permite editar archivos de Office manteniendo su formato o convertirlos al formato de Google, generando una copia. Algunas funciones requieren conversión. También admite importar, exportar, copiar y pegar Markdown, útil para intercambiar texto estructurado con otras herramientas.
Definir qué archivo es el original de trabajo antes de convertir. Una copia nueva puede tener enlaces, permisos o historial diferentes. En un intercambio con Word, comprobar tablas, imágenes, comentarios y propuestas de cambio, además del texto visible.
Markdown resulta práctico para contenido textual, pero no reproduce toda la maquetación de un documento. Elegir el formato por el uso posterior: edición, publicación o consulta estable. La entrega debería permitir reconocer la versión aprobada sin depender de nombres ambiguos como «final definitivo».
Documentación de referencia: Work with Microsoft Office files · Use and exchange Markdown.
Trabajo sin conexión y sincronización
En ordenador, el acceso sin conexión requiere preparación con Internet, Chrome o Edge y la extensión Google Docs Offline. No se utiliza navegación privada. La disponibilidad depende también de configuración administrativa y del espacio local necesario.
Antes de una visita, abrir y preparar el documento concreto. Después, desconectar realmente el equipo y comprobar lectura y edición con contenido de prueba. Al recuperar conexión, confirmar que los cambios aparecen en la versión compartida.
Separar una nota de campo de una instrucción vigente. Una copia local puede ser útil para redactar, pero no debería ocultar que existe una actualización posterior. Definir cómo se identifican las versiones y qué hacer cuando no se puede consultar el repositorio habitual.
Documentación de referencia: Work on Google Docs offline.
Chips inteligentes e integración con AppSheet
Los chips inteligentes aportan contexto sobre personas, archivos, fechas, eventos y lugares. Mencionar a alguien mediante un chip no le concede acceso automáticamente. La integración de AppSheet permite consultar vistas compatibles e interactuar con datos, respetando permisos y políticas de la aplicación.
En un plan de campaña, un chip puede ayudar a localizar el material o la reunión de referencia. Debe quedar claro si se enlaza un borrador, un recurso aprobado o una aplicación operativa. La comodidad de la referencia no sustituye la revisión del contenido enlazado.
Si se utilizan acciones de una aplicación, probarlas con roles reales y registros ficticios. Un documento de consulta y una interfaz que modifica datos tienen consecuencias distintas. Explicar a la persona cuándo está leyendo y cuándo está realizando una operación.
Documentación de referencia: Insert smart chips in Google Docs · Use AppSheet smart chips in Docs.
Idiomas, dictado y redacción accesible
Docs permite traducir un documento a una nueva copia y dispone de escritura por voz en entornos compatibles. Google recomienda encabezados, enlaces descriptivos y texto alternativo para mejorar accesibilidad. Las funciones de idioma deben comprobarse para el entorno utilizado.
En SST, una traducción necesita revisión terminológica y operativa. Mantener coherencia entre riesgo, peligro, medida preventiva y acción correctiva exige contexto. Comparar condiciones, unidades y excepciones entre idiomas, además de corregir gramática.
Para una guía, probar si una persona puede encontrar una instrucción concreta con teclado o ampliación. Describir lo que aporta una fotografía y evitar referencias basadas solo en color o posición. La redacción accesible también exige frases que expliquen quién debe hacer qué y cuándo.
Documentación de referencia: Translate documents or change writing language · Type and edit with your voice · Create accessible documents.
Gemini y documentos generados con contexto
Gemini puede preparar borradores, ampliar texto y utilizar fuentes de trabajo para contextualizar una respuesta. La creación personalizada admite referencias de Drive, Chat, Gmail y web según disponibilidad. Requiere un plan elegible y sus funciones pueden variar por cuenta y plataforma.
La ayuda actual de Google describe Gemini como asistente integrado. Las menciones históricas a Explore en reseñas antiguas no deben utilizarse como descripción de la interfaz actual. Identificar la función concreta evita atribuir capacidades o límites de una etapa a otra.
Para un borrador de SST, indicar objetivo, público y fuentes autorizadas. Pedir que se señalen los datos ausentes y revisar cada afirmación importante contra su origen. Una síntesis puede omitir una excepción decisiva; la revisión debe comprobar significado, no solo fluidez.
Documentación de referencia: Create personalised documents with Gemini · Collaborate with Gemini in Google Docs.
Complementos y Apps Script
Apps Script permite crear y modificar documentos y añadir menús, diálogos o paneles. La estructura actual incluye pestañas, por lo que una automatización debe identificar qué parte modifica. Los scripts actúan con permisos y pueden distribuirse como complementos.
Un uso propuesto es generar borradores uniformes desde una lista de actividades: título, centro, fecha y responsable. La salida debería quedar marcada como borrador hasta revisión. Comprobar campos vacíos, caracteres especiales y duplicados antes de procesar muchos registros.
La automatización necesita propietario y mantenimiento. Registrar versión de plantilla, fuente de datos y resultado generado permite corregir errores sin reconstruir todo el proceso. Una ejecución terminada no demuestra que cada documento sea completo o apropiado para su destinatario.
Documentación de referencia: Extend Google Docs with Apps Script.
Cuenta personal, Workspace y tratamiento de datos
Las condiciones de una cuenta personal y las de un entorno administrado deben evaluarse por separado. Para los servicios generativos de Workspace, Google declara que no utiliza datos de clientes para entrenar sus modelos sin permiso o instrucción del cliente. Esa condición tiene un ámbito contractual concreto.
Antes de introducir información preventiva, identificar qué datos hacen falta, quién puede acceder y cuánto tiempo se conservarán. Para preparar una guía general no suelen necesitarse historiales personales. Separar contenido público, documentación interna y datos sensibles facilita el control.
Las integraciones también forman parte del recorrido de los datos. Revisar permisos de complementos y fuentes conectadas, y retirar accesos que ya no sean necesarios. La facilidad de compartir debe acompañarse de una definición clara de audiencia y finalidad.
Documentación de referencia: Google Workspace generative AI privacy hub.
Incidentes históricos y continuidad documental
En mayo de 2017 una campaña suplantó invitaciones de Google Docs para obtener permisos de cuenta mediante una aplicación falsa. Google informó de retirada de aplicaciones y revocación de accesos. Fue un abuso de autorización y suplantación, no una función legítima de colaboración.
El 31 de octubre de 2017 un error de los sistemas de protección bloqueó archivos legítimos al identificarlos incorrectamente como infracciones. Google explicó el fallo y la restauración de accesos. Ambos hechos son antecedentes históricos, no pruebas de un incidente actual.
La lección operativa propuesta es doble: verificar solicitudes de acceso y preparar continuidad para documentos relevantes. Conservar una copia aprobada accesible según el plan de la organización permite mantener consulta cuando el servicio o la cuenta no están disponibles, sin crear una biblioteca paralela sin control.
Documentación de referencia: Google response to May 2017 phishing campaign · Google explanation of October 2017 access error.
Capacidad y límites de documentos extensos
Google establece 1,02 millones de caracteres por documento y 50 MB para convertir texto a Docs.
Para bibliotecas de SST, dividir por necesidades de consulta y propiedad editorial. Un único documento que acumula todos los procedimientos puede dificultar permisos, revisión y localización. Separar documentos tampoco debe romper referencias o multiplicar instrucciones repetidas.
Probar con contenido representativo: tablas largas, imágenes y varias personas revisando. Medir facilidad de encontrar una respuesta y resolver comentarios, además del tiempo de carga. La organización documental tiene más valor que alcanzar el máximo técnico admitido.
Documentación de referencia: File limits in Google Drive and Docs.
Aplicaciones concretas en SST
En seguridad y salud en el trabajo puede apoyar la preparación conjunta de borradores, actas y guías internas. Facilita recoger observaciones de diferentes áreas en un documento común, siempre que se establezca quién revisa, quién aprueba y qué versión se considera válida para su utilización.
Además de actas, se propone usarlo para reunir aportaciones a una guía de acogida y preparar preguntas de una consulta a trabajadores. En una guía, las áreas pueden comentar un párrafo común en lugar de enviar copias divergentes. En la consulta, un borrador compartido permite detectar preguntas ambiguas antes de recoger respuestas, sin almacenar en el mismo documento información personal innecesaria.
Caso práctico y comprobación del resultado
Para el acta, separa asistentes, asuntos tratados, acuerdos y cuestiones pendientes. Asigna a una persona la consolidación y pide que las correcciones se formulen como sugerencias o comentarios, explicando si afectan a un hecho, una redacción o una decisión. Una discrepancia sobre lo acordado no debe resolverse solo porque alguien edite el texto más tarde.
Tras revisar las aportaciones, identifica explícitamente qué texto se aprueba y nombra esa versión. Comprueba responsables, fechas y acciones contra las notas autorizadas de la reunión. Ajusta los permisos de la copia de consulta según la audiencia y prueba el acceso desde una cuenta con el rol previsto. Si después aparece una corrección, documenta la nueva versión y su relación con la anterior en vez de sustituirla silenciosamente.
Límites y condiciones de uso
Compartir un enlace no equivale a controlar su audiencia. Revisa permisos y evita introducir datos de salud o información personal innecesaria. El historial ayuda a seguir cambios, pero no sustituye al proceso formal de aprobación, conservación y acceso que la organización necesite para sus documentos preventivos.
Google indica que consultar versiones anteriores requiere permiso de edición. Por tanto, un lector no necesariamente puede reconstruir el historial que ve el equipo redactor. Restaurar una versión es una operación distinta de crear una copia para compararla. Al convertir entre documentos de Google y Microsoft Office, sugerencias y cambios registrados se trasladan entre formatos; revisa esa información antes de compartir el archivo convertido.
Documentación de referencia: Suggest edits in Google Docs · Version history, named versions and access.
Cuándo elegirla y con qué complementarla
Google Docs encaja cuando varias personas necesitan colaborar sobre un texto común y la organización ya controla sus cuentas y permisos. Word es una comparación útil para revisión y maquetación documental. Google Slides puede presentar los acuerdos al equipo, manteniendo el acta como referencia de detalle.
La decisión debe considerar cómo se aprobará el texto, cómo accederán personas externas y cómo se conservará una copia utilizable fuera de la edición diaria. Prueba el flujo completo con un acta ficticia.
Preguntas frecuentes
¿Aceptar una sugerencia equivale a aprobar el documento?
No. Aceptar una propuesta modifica el texto. La aprobación del conjunto depende del procedimiento y de la autoridad definida por la organización.
¿Una versión con nombre queda bloqueada?
El nombre identifica un estado del historial; no debe confundirse con una prohibición de nuevas ediciones. Define permisos y una versión de consulta cuando necesites estabilidad.
¿Conviene dar edición a todas las personas?
Solo cuando su función lo requiera. Quien revisa puede necesitar comentar; quien consulta puede necesitar únicamente leer. Comprueba el acceso efectivo, incluyendo enlaces compartidos anteriormente.
