In 2026, it is hard to find a document management platform that does not promise centralisation, automation, integration, security and artificial intelligence. The vocabulary has converged. However, the real capability of the solutions has not always followed.
An organisation can compare dozens of features and watch a smooth demonstration. Even so, it may still choose a platform that does not reflect its rules, handles exceptions poorly or creates costly dependencies. The problem lies not only in what the company asked the supplier, but above all in how it formulated and validated its requirements.
For example, “Does it have workflow?” is too vague a question. In contrast, “Can it apply different criteria to the same document depending on the contract, the activity, the workplace and the risk level, while keeping a history of the rule used in each decision?” lets you observe a concrete capability.
This is the leap companies need to make: moving from a list of features to an evidence-based set of requirements. The platform needs to protect documents and decisions, adapt to the operation and communicate with other systems. In addition, it must use automation or AI without turning speed into a loss of control.
The starting point: Demand verifiable results, not labels
A feature is only a technical possibility. In contrast, a useful requirement describes the result needed, the context in which it must work and the evidence that will prove compliance with it.
For example, “advanced search” can mean anything from a single text field to a search by metadata, content, entity, status, expiry date, contract and permissions. Similarly, “API integration” may refer to a handful of operations or to a documented, monitored architecture that suits the process. Likewise, “document AI” may be a prepared demonstration or a capability you can measure by document type, language and confidence level.
Before approaching the market, classify each need into three groups:
- Minimum requirement: without this capability, the platform neither protects the process nor meets the organisation’s objective.
- Context-dependent capability: it may be decisive for certain sectors, operations or user profiles, but it is not universal.
- Desirable evolution: it creates future value, provided there is a use case, governance and a realistic path to adoption.
This classification avoids two extremes: buying an inadequate solution because the presentation looks simple, or buying complexity that the company will not be able to use.
First requirement: Document control throughout the entire life cycle
A document management platform is not just a place where files are available. Instead, it must control the creation or receipt of each document, its classification, validation, versions, use, renewal, retention and final disposition, in line with the organisation’s rules.
ISO 15489-1 sets out principles for creating, capturing and managing records, regardless of format or technological environment. The relevant elements include metadata, responsibilities, controls, monitoring and the maintenance of evidence over time. For a company, therefore, this translates into a practical question: does the platform preserve only the PDF, or also the context needed to understand what it proves?
In an operation with contractors, a document may relate to a company, a worker, a piece of equipment, a contract and a workplace. In addition, its validity may depend on dates, the activity, the issuing body, the version and local criteria. For this reason, a suitable platform needs to keep these relationships without forcing the team to rebuild them in spreadsheets.
What to demand: structured metadata, version control, relationships between entities, validity and retention rules, search consistent with permissions and preservation of the relevant history.
How to prove it: give the supplier a set of related documents and ask them to demonstrate receipt, classification, modification, renewal, search and export. Also include a superseded version and an exception.
Second requirement: Traceability that reconstructs the decision
An activity log stating that someone “changed the document” is not enough for an audit or for investigating an incident. Instead, the organisation must be able to answer: who made the decision, when, with which profile, on which version, under which rule, with which data, and what actions followed?
This requirement becomes more important when the platform automates steps or uses AI. If the platform rejects a document, for example, knowing the outcome is not enough. You need to distinguish between an automatic rule, an algorithmic recommendation, a human decision and a later change. Likewise, it must be possible to identify replacements, reopenings, exceptions and conditional approvals.
Good traceability protects the organisation and improves the process. In addition, it helps you find ambiguous criteria, variations between reviewers, rules that generate excessive rejections and stages where work stalls.
What to demand: chronological history, identity and profile of the person involved, document version, applicable rule or criterion, data source, automatic and human decisions, justifications and exception management.
How to prove it: select an old decision and ask for a complete reconstruction of it. Next, change a rule and confirm that the system preserves the distinction between decisions made before and after the change.
Third requirement: Demonstrable security, privacy and continuity
“The platform is secure” is not a requirement. Rather, it is a claim that you need to break down into controls, responsibilities and evidence.
The NIST Cybersecurity Framework 2.0 organises risk management into six functions: Govern, Identify, Protect, Detect, Respond and Recover. This view is useful because it stops the assessment from focusing only on access control. After all, a platform may authenticate users correctly and still have gaps in detection, incident response, recovery or supply chain management.
When a platform handles personal data, its design must include data protection by design and by default, with continuous review. This means limiting access and processing to what is necessary, defining retention periods, separating profiles and understanding processors. It also means preventing the reuse of customer data for other purposes without an appropriate legal basis and information.
What to demand: role and context-based access control, risk-appropriate authentication, encryption, protected logs, vulnerability management, backups, tested recovery, incident response, data location and data flows, identified processors and privacy-by-design mechanisms.
How to prove it: request technical and contractual documentation, results or summaries of appropriate tests, agreed recovery times, a responsibility matrix and an access exercise. In practice, a user should see exactly what they need, without receiving information from another company, contract or process.
Fourth requirement: Configuration with autonomy and governance
Document processes change: new fields, document types, criteria, alerts, languages, profiles and approval routes appear. So the question is not whether there will be changes, but how much time, cost and risk each change will introduce.
A configurable platform lets you adapt data, rules and workflows without turning every change into a development project. However, autonomy without governance also creates problems. Changes made directly in production, without testing, approval or history, can compromise decisions and reports.
The right requirement, therefore, is not “no-code” on its own. Rather, it is configuration capability with test environments or mechanisms, administrative permissions, version control, documentation and the ability to roll back.
What to demand: configuration of fields, forms, rules, alerts, profiles, dashboards and flows; separation between configuration and custom development; change control; testing; history; and clarity about what the customer’s team can manage.
How to prove it: during the demonstration, ask for a change that nobody has prepared in advance. A good test is to create a new document requirement for one category of equipment only, at one workplace, with an early alert and an exception route. Then measure who carries it out, how long it takes and what contractual impact it would have.
Fifth requirement: Integration and portability to avoid new silos
Document management rarely works in isolation. It receives data from ERP, human resources, procurement, HSE systems, identity directories, access platforms and operational applications. Equally, it needs to send back statuses, blocks, expiry dates, evidence and indicators.
Confirming that an API exists is not enough. You also need to know which objects and actions are available, how authentication works and whether there are events or notifications. Likewise, check how the system handles errors, which limits apply and who monitors the integration.
Portability deserves the same attention. The European Data Act, applicable since September 2025, strengthens the rules on switching between data processing services. These include contractual provisions, open interfaces and the export of exportable data and digital assets. Legal advisers should confirm how it applies to each service and contract, but the direction is clear: you cannot leave access and exit until the time of migration.
What to demand: documented and sufficient APIs, monitorable integration mechanisms, a clear data ownership model, export of documents, metadata, versions, relationships and histories, usable formats, exit conditions and transition support.
How to prove it: carry out an integration or simulation with process data and an independent export. Then confirm not only that the files come out, but also that they keep the structure, identifiers, relationships and enough context for reuse.
Sixth requirement: An experience suited to real work
A platform can technically meet every requirement and still fail because it forces users to work around the interface. In document management, this friction leads to incomplete submissions, repeated rejections, calls, emails and information recorded outside the system.
Each profile has different needs. An administrator configures. A reviewer, on the other hand, compares evidence with criteria, while a manager looks for risk and priorities. Meanwhile, a field worker needs to complete a task quickly on a mobile device. Finally, an external supplier needs to understand what is missing and how to fix it.
Design should reduce ambiguity and effort, not hide complexity. In fact, clear rejection messages, consistent actions, fast search, visible context and appropriate mobile journeys are operational capabilities, not aesthetic details.
What to demand: role-based journeys, mobile use where relevant, accessibility, suitable wording and languages, clear statuses and messages, contextual help, effective search and less duplicate data entry.
How to prove it: ask representative users to perform tasks without extensive prior training. Then measure the completion rate, time, errors and questions. Also include at least one external contractor and one field task, if they are part of the process.
Seventh requirement: Automation that handles exceptions without hiding risk
Automating a perfect path is relatively simple. The quality of the platform, however, shows when information is missing, a date is inconsistent, documents contradict each other or a rule does not fit the case.
Responsible automation must distinguish clear cases from situations that require review. In addition, it must route exceptions to the right person, explain the reason, prevent unsafe decisions and keep human intervention possible. It also needs to avoid silent loops, tasks without an owner and excessive notifications.
What to demand: transparent rules, exception handling, service levels, escalation, relevant alerts, prevention of duplicate runs, failure monitoring, the option to intervene and a record of each automatic action.
How to prove it: test a normal case and several difficult ones: an illegible document, a missing field, a contradictory expiry date, a duplicate, a rule with no match and an integrated system that is down. The demonstration should show how the process fails, recovers and reports, not just how it runs when everything is right.
Eighth requirement: Useful, measurable AI subject to human oversight
In 2026, AI can already support classification, information extraction, comparison with requirements, anomaly detection, translation and decision preparation. However, this does not mean that every company needs the same AI, or that anyone should treat a generated answer as the truth.
The EU Artificial Intelligence Act (AI Act) is now an essential reference in the European Union, with phased application and amendments introduced in 2026. Nevertheless, the classification and obligations depend on the use case. Regardless of the specific legal framework, principles such as human oversight, documentation, logging, robustness, cybersecurity and accuracy control are prudent criteria for any document process with operational impact.
The NIST AI Risk Management Framework reinforces the need to measure, document and track oversight, errors, complaints, overrides of automatic recommendations and policy exceptions. For anyone buying a platform, this means asking how the AI behaves when it does not know.
What to demand: clearly defined use cases, metrics by document type and language, confidence levels, enough explanation for review, configurable human oversight, logging of inputs and outputs, error management, data protection and clarity on whether the supplier uses customer data to train or improve models.
How to prove it: use a representative sample from your own organisation, including low-quality documents, relevant languages and exceptions. Then measure correct extraction, false positives, false negatives, routing to review and human time saved. Never accept only the sample the supplier has prepared.
Ninth requirement: Operational data that leads to action
Colourful dashboards do not guarantee management. Therefore, the platform must produce consistent, current and explainable information that connects to the source entities and decisions.
For HSE/EHSQ and contractor management, you may need to know about documents close to expiry, rejection causes, validation times, workload per team, compliance by contract, blocked workers, pending equipment or risk concentration. The indicator must then let you drill down to the specific case and act.
It is equally important to know the quality of the data itself. Indeed, empty fields, duplicates, inconsistent classifications and delayed integrations reduce trust and limit any future automation.
What to demand: configurable indicators, filters and drill-down, a known update frequency, traceability to the source, controlled export, defined calculations, actionable alerts and data quality metrics.
How to prove it: hand over three management questions and ask the supplier to answer them live. Then choose a value on the dashboard and follow the path back to the documents, rules and decisions behind it.
Tenth requirement: Transparent evolution, support and total cost
Selection does not end at go-live. The organisation needs to know how the supplier will support, update and adapt the platform over the years.
The initial price rarely represents the total cost. Licences, implementation, configuration, migration, integrations, storage, environments, support, training, changes, AI usage and exit may follow different pricing models. As a result, the risk increases when the boundaries between configuration, consultancy and development are unclear.
A sustainable technology relationship requires clear responsibilities, service levels, an escalation process, transparency about product evolution and conditions for recovering the data. Furthermore, it requires distinguishing a roadmap promise from a contractual commitment.
What to demand: an understandable pricing model, volume assumptions, costs of routine changes, support and service levels, update policy, compatibility, supplier continuity, product limits, exit conditions and the responsibilities of both parties.
How to prove it: calculate three or five-year scenarios with growth, new integrations, process changes, greater usage and a possible transition. Then ask the supplier to describe each uncertain cost rather than hide it in a generic category.
Not everything should be mandatory for every company
A mature assessment avoids turning trends into universal requirements. For instance, offline mobile operation, multiple languages, automatic identification, integration with access control, inspection modules, electronic signatures or certain AI models may be essential in one context and irrelevant in another.
For this reason, each requirement should link to a risk, objective, user or decision. If the team cannot explain what problem it solves and how it will measure the result, it should question whether it is buying capability or just possibility.
The opposite is also true. A seemingly specific requirement may be structural for the operation. For example, a company with hundreds of contractors across several workplaces should not accept rule management that ignores the contract, activity and location. Similarly, an organisation with field work should not treat the mobile experience as a decorative extra.
The benchmark should be demanding, but contextual.
How to turn requirements into a demonstration that reveals the platform
Sales demonstrations tend to show the best path, with prepared data and experienced users. To reduce this imbalance, the company should therefore give all suppliers a common script.
Use a complete process from your organisation
Choose a case with volume, impact and diversity: contractor pre-qualification, worker documentation, equipment authorisation or expiry date management. Also include anonymised or synthetic data with the same structure as the real process.
Include a difficult exception
Add an illegible document, a context-dependent expiry date, a version replacement, a worker linked to more than one contract or an approval that requires justification. After all, the limits of the data model and the workflow appear precisely in the exceptions.
Ask for a live change
Introduce a field, a rule, an alert or a profile that was not in the initial script. The aim is not to catch the supplier out, but to observe the autonomy, method, time and governance of the configuration.
Test the exit before the entry
Ask for an export with documents, metadata, relationships, versions and history. You should validate portability before signing, while the company still has bargaining power.
Observe each profile
Include the administrator, the reviewer, the manager, the mobile user and the external party, where applicable. Do not accept the experience of a single profile as representative of the whole operation.
Record evidence and acceptance criteria
For each critical requirement, define the expected result, the test scenario, the evidence, the person responsible for validation and the consequence of non-compliance. An authorised recording, a pilot report and a deviation matrix are worth more than scattered meeting notes.
The contract should reflect what drove the choice
If a capability was decisive, it should not disappear between the proposal and the contract. Therefore, identify integrations, volumes, configurations, responsibilities, service levels, migration, acceptance criteria, data processing, AI usage, support, updates and exit.
Avoid wording where everything depends on “further analysis”. Some uncertainties are legitimate, especially in integration and migration, but they must have assumptions, limits and a decision process.
It is also important to establish governance on the customer side. Who decides the document rules and who can configure them? Who approves changes? Finally, who monitors data quality, security, access, AI performance and adoption? In short, a good platform does not replace organisational responsibilities.
The document management platform of 2026 must help the company change
The best criterion is not the number of modules, but the ability to stay in control while the organisation evolves.
In summary, a suitable platform protects the document and its context, reconstructs decisions, limits access and integrates data. It also allows process changes with governance, handles exceptions and gives users a consistent experience. When it uses AI, it measures results, shows uncertainty and preserves human oversight. Finally, when the relationship ends, it returns usable information.
GEDOC presents a new generation of AI-powered HSE platform that is fully configurable, no-code and ready for integration. The offer published on the website covers the management of companies, workers, equipment and processes, document reading and analysis, workflows, alerts, dashboards and human oversight at critical points.
To assess whether this approach fits your reality, bring a real process, a difficult exception and a change your company needs to make to the demonstration. The conversation becomes more useful when it stops being “what does the platform have?” and becomes “how do you prove you can operate, control and evolve with us?”.
Find out more: How to choose a document management platform.
See also: Selecting document management platforms: Process and criteria and Cost control when selecting a document management platform.
Frequently asked questions
What are the minimum requirements for a document management platform in 2026?
Control of documents and metadata throughout the life cycle, traceability, security and privacy, search, version management, configuration, integration and portability. Also an experience suited to each profile, automation with exception handling, explainable reporting, support and transparent commercial terms. However, the importance of additional capabilities depends on the process and the risk.
Does a platform need artificial intelligence to count as modern?
Not necessarily. You should judge modernity by suitability, security, openness and the ability to evolve. When AI solves a real case, the company should demand metrics, human oversight, traceability, data protection and error management. Otherwise, an AI label without proof adds no value.
How can you compare platforms without getting stuck on feature lists?
Turn each critical requirement into a scenario, an expected result and a piece of evidence. Then use the same process and the same exception cases with every supplier. Finally, include live configuration, export, role-based journeys and acceptance criteria.
What should a proof of concept test?
A complete process, representative data, contextual rules, exceptions, priority integrations, user experience, report quality and portability. If the platform uses AI, also test accuracy and routing to human review. The proof should measure results and operational effort.
How do you assess a document management API?
Check the available data and actions, documentation, authentication, limits, events, error handling, monitoring, versioning and costs. An API exists to support specific processes; on its own, however, its presence does not guarantee sufficient integration.
Which costs should the total cost of ownership include?
Licences, implementation, configuration, migration, integrations, storage, environments, support, training, changes, AI service consumption, volume growth and exit. You should estimate them in realistic scenarios, with documented assumptions.
ISO, ISO 15489-1:2016, Information and documentation, Records management, Part 1: Concepts and principles.
NIST, The NIST Cybersecurity Framework (CSF) 2.0.
European Data Protection Board, Data protection by design and by default.
European Union, Regulation (EU) 2023/2854, European Data Act.
European Commission, AI Act, Regulatory framework for AI.
European Commission, “AI Omnibus enters into force”.
NIST, AI Risk Management Framework Playbook, Measure.