DocPilot FAQ

DocPilot is a multi-tenant AI document management system: it centralizes documents and contracts, reads their content (OCR + DocpilotAI), then runs approval workflows through to archiving in a searchable repository.

Legal, procurement, finance and executive teams, as well as SMBs that want a clear document process without a complex document management project or an external BPM engine.

Scattered documents, contracts lost in e-mail, manual re-keying, slow approvals and no clear view of where a file stands.

Yes. DocPilot is a multi-tenant SaaS: each organization has its own workspace. The active organization comes from the authenticated session, not from a client-side parameter that could be tampered with. Isolation is enforced in the database (RLS) and in object storage (dedicated prefix). See also the Security page.

The DocPilot website and applications are hosted on cloud infrastructure in the European Union.

No. The product describes design practices (multi-tenant isolation, audit, immutable originals, antivirus scanning on e-mail ingestion). No ISO, SOC 2 or HDS certification, and no regulatory guarantee, is claimed on this site. See the Security page.

For e-mail ingestion, an antivirus scan (ClamAV) runs before OCR and routing. Web uploads check the file type (magic bytes) at finalization; file access goes through time-limited signed URLs.

Yes. An append-only audit log records sensitive actions and workflow progress: who received, confirmed, approved, rejected or requested a change, and when.

The service is designed to comply with the GDPR (EU hosting, data subject rights, documented sub-processors), without claiming absolute certified compliance. A summary is on the GDPR page; processing details are in the privacy policy.

OCR makes the file’s content readable (native text or optical character recognition). It is the first step of the reading pipeline, separate from the business approval workflow. A preview can also be generated for viewing.

Yes. Documents can arrive by e-mail, web upload or mobile photo. The pipeline then reads the file to produce text that classification, extraction and search can use.

Yes. OCR (and LLM) providers are chosen per organization. DocPilot does not claim to train models on your contracts.

It suggests a document type, extracts the fields defined for that type (number, parties, dates, amounts, key clauses, etc.) and fills in the record with a confidence score and its source. You confirm before the workflow starts.

No. DocpilotAI suggests; approvals stay human and logged. Approving, rejecting or requesting a change is a human decision in the workflow.

The document does not move on to the workflow automatically. It goes to human review: an authorized user corrects the fields, the history keeps the previous extraction, and the workflow can then start on the corrected version. Originals are never overwritten.

You pick the type in one click; extraction runs again using the schema for that type.

Once the text is available, you select one or more documents and ask a question. DocpilotAI answers from their content (document assistant on web and mobile).

No. No training on your contracts is claimed. The OCR / AI model (provider) policy can be set per organization.

A contract is a business object separate from the file: parties, amount, dates, department, owner, expiry date, and a link to one or more documents. Its business status follows the progress of the approval workflow.

No, that is not the core of the product today. DocPilot manages the life of documents and approvals around the contract (receipt, reading, workflow, archiving).

On the web: the contract list (title, reference, workflow status, department, owner, expiry date) with a link to the related document. On mobile: creating and tracking small contracts, alongside the approval inbox.

No. Workflows are built in: versioned definitions, one active version per document type, inbox tasks, approval actions and an immutable log. OCR and extraction remain a separate pipeline, triggered before the business workflow.

Each organization defines its own workflows. A step can be assigned to a user, a role, a department (e.g. legal) or a domain (e.g. procurement). “Any one”, “all” or quorum modes fit the decision to how the team works.

Organization administrators (and roles with the relevant permissions) publish the versioned definitions. Approvers handle tasks without changing the workflow.

After successful document routing: type confirmed, sufficient confidence (or human review completed) and an active workflow linked to the type. The instance is locked to the workflow version in force when it starts.

System roles include: organization administrator (team, departments, domains, workflows), manager, approver (inbox), user (upload and viewing within their scope) and viewer (read-only).

From the Team page, an administrator sends an invitation with a role. The colleague activates their account via the link received by e-mail, enters their details and chooses a password, then joins the organization’s workspace.

The web app covers full document management, administration and workflow configuration. The mobile app is built for the approval inbox (view, approve, reject, request a change) and light contract tracking — not to replicate the whole document management system.

DocPilot combines a role (RBAC) with scopes: department, domain and document grants. Access rights follow this structure; everyone sees only their own scope.

Not necessarily. On top of the role, access can be restricted by department and by domain. Two approvers can therefore have different queues and files.

Downloading the original depends on the documents.download permission, granted by role and scope — not automatically to every member of the organization.

By e-mail (the organization’s ingestion address), by web upload, or as a photo from the mobile app. Processing (checks, OCR, extraction, then any workflow) then starts asynchronously.

No. The web interface offers a filterable list, metadata (department, domain, tags) and search — not a folder explorer. Visibility always respects each user’s scope, with no leakage between organizations.

No. Originals are immutable: a new version is added on top, and the history of versions and extractions is kept. Nothing is silently overwritten.

The document may be flagged with a technical failure status. Check the format and size, then rerun processing or upload the file again. Metadata and history remain available for troubleshooting.

The web app offers full-text search and filters. You can search the title, OCR text, contract number, parties and tags, then filter by type, department, domain, status and dates.

No. Classification (department, domain, tags) helps with routing and filters, but search also relies on the OCR content and extracted fields. There is no folder tree to maintain by hand.

After classification (department, domain) and AI reading, the document follows its workflow. Each approver can approve, request a change or reject. Decisions are logged.

Yes. The mobile app is built for the approval inbox: view the document, see the extracted data, approve, reject or request a change.

Yes: in-app notifications and e-mails depending on the organization’s settings (document received, task to handle, decision made).

After approval (or according to the organization’s business lifecycle), the file moves to archived status and stays in the organization’s repository, with its history.

Yes. Archiving keeps the file in the repository: it remains searchable, with the audit log and version history. It is not a deletion.

The business lifecycle includes: draft, in review, approved, rejected, changes requested, archived — in addition to the pipeline processing status (extraction, routing, failure, etc.).