DocxIntel home
DocxIntel, a product of BizfyLabs
DocxIntel, a product of BizfyLabs
by
BizfyLabs
  • Capabilities
    • Analyse

      Resolve layout, reading order, tables and handwriting

    • Identify

      Pull entities, fields and clauses with coordinates

    • Classify

      Sort document types and split multi-page packets

    • Map

      Link and reconcile entities across your estate

    • Modify

      Redact, mask and transform documents safely

    • Ask

      Query your documents and get cited answers

    • All six capabilities, one platform→
  • Deployment
  • Accuracy
  • Industries
    • Banking & Financial Services

      Statements, KYC files, and financial filings

    • Insurance

      Claims, policies, and underwriting documents

    • Government & Public Sector

      Records, correspondence, and regulatory filings

    • Healthcare

      Patient records, referrals, and lab reports

    • Legal & Compliance

      Contracts, filings, and case documentation

    • Energy & Utilities

      Engineering documents, contracts, and reports

    • Every regulated industry we serve→
  • Pricing
  • Docs
Book a Demo
Home
DocXIntel

Menu

    • All capabilities
    • Analyse
    • Identify
    • Classify
    • Map
    • Modify
    • Ask
    • All industries
    • Banking & Financial Services
    • Insurance
    • Government & Public Sector
    • Healthcare
    • Legal & Compliance
    • Energy & Utilities
    • Deployment models
    • Reference architectures
    • Sizing & throughput
    • What's in the box
    • Security posture
    • Documentation
    • Accuracy benchmark
    • Pricing
    • Proof of Value
    • Compare
    • About
    • FAQ
    • Contact Us
Security posture

The strongest security control is that your documents never leave your perimeter.

Most document AI security pages describe how carefully a vendor guards your data after you have sent it to them. DocxIntel removes that step. The platform, the models and the keys sit inside your infrastructure, so the controls your auditors already trust are the controls that apply.

  • No egress, no phone-home
  • You hold the keys and the weights
  • Single-tenant by construction
  • Signed images and published SBOM
Request the security pack
Deployment models
Air-gapped DocxIntel deployment topology showing no outbound network path from the customer perimeter
0 bytes
Outbound to BizfyLabs
verifiable with egress monitoring
Your KMS
Encryption keys
never generated or escrowed by us
Single tenant
Every deployment
no shared infrastructure exists
Signed
Images and model bundles
checksums published per release

These are architectural properties, not policy commitments — they hold because there is no vendor-side service for your data to reach, in any deployment model including private cloud and managed single-tenant.

The argument

Architecture beats policy, because architecture cannot be misconfigured back.

A cloud document service can encrypt in transit, isolate tenants, rotate keys and publish an attestation, and all of it can still be undone by one misconfigured bucket, one over-broad support role or one subprocessor change buried in a policy update. Removing the network path removes the entire class of failure rather than mitigating it.

  • No third-party subprocessor handles your documents, so there is no subprocessor list to monitor and no change notice to review
  • No vendor support engineer can be socially engineered into accessing your data, because no vendor-side copy exists to access
  • No cross-border transfer question arises, because the data never crosses a border — the residency argument is the deployment diagram
  • Model weights are delivered to you and load from local storage, so inference cannot silently fall back to a hosted endpoint
  • A breach at BizfyLabs cannot expose your documents; the worst case is a compromise of our build pipeline, which is why images are signed and checksummed

This is also why the security review during a Proof of Value is conducted against the deployed system in your own environment, rather than against a questionnaire about ours.

DocxIntel private cloud reference topology with API gateway, GPU workers, object storage and PostgreSQL inside the customer VPC
Control catalogue

Tenancy, identity, encryption, audit and retention

The controls a security team asks about first, described as they are implemented rather than as they are aspired to. The full pack, including the framework mapping, is available under NDA.

Tenancy and isolation

Tenancy model
Single-tenant by construction. Every deployment is a dedicated install of the platform on infrastructure you control; there is no multi-tenant service and therefore no tenant-separation logic to fail.
Network isolation
Services run in a dedicated namespace or Docker network with explicit ingress rules. Outbound egress can be set to default-deny with no loss of function, including model loading and licence validation.
Workload hardening
Containers run as a non-root user with read-only root filesystems where the component permits, no privileged containers, and resource limits per workload. Kubernetes manifests ship with baseline network policies and pod security settings.
Environment separation
Production, disaster recovery and non-production are separate installs with separate credentials and separate storage. No shared control plane spans environments.

Identity and access

Authentication
OIDC and SAML 2.0 single sign-on against your own identity provider, with your MFA and conditional-access policies applied. Local accounts exist for break-glass use and can be disabled entirely.
Authorisation
Role-based access control mapped to your directory groups, with separate roles for administration, schema configuration, review-queue work and read-only audit access.
Least privilege
Service accounts are scoped per component with the narrowest storage and database grants that function. Administrative actions are separated from document access, so a platform administrator need not be able to read claim contents.
Permissions-aware retrieval
Question answering and search respect the document permissions of the asking user. A user cannot retrieve, cite or summarise a document they are not entitled to open — the access check happens at retrieval, not in a prompt instruction.

Encryption and key custody

In transit
TLS 1.2 or 1.3 on every interface, including service-to-service traffic inside the cluster, using certificates issued by your own PKI or your service mesh.
At rest
AES-256 for documents, extraction output, database contents and backups, applied through your storage and database encryption or the bundled configuration where you prefer it.
Key custody
Your KMS or HSM holds the keys. DocxIntel does not generate, escrow, export or transmit key material, and BizfyLabs holds no copy of any customer key. Rotation follows your policy and schedule.
Secrets management
Credentials are read from your secret store or from Kubernetes secrets backed by it. Nothing is baked into an image, and no default credential ships enabled.

Logging and audit trail

What is logged
Authentication, authorisation decisions, document access, extraction runs, schema and configuration changes, review-queue decisions, redaction actions and administrative operations — each with actor, timestamp, source and object.
Immutability
Audit records are append-only and can be streamed to your SIEM or to write-once storage, so the tamper-evidence guarantee comes from infrastructure you already have accredited.
Field-level provenance
Every extracted value retains its page number, bounding-box coordinates and confidence score, so an auditor can trace a posted figure back to the source region months later without re-running anything.
Export
Structured JSON logs to stdout, syslog or your collector, plus Prometheus metrics. Monitoring stays inside your estate — there is no vendor observability endpoint.

Data lifecycle and retention

Where data lives
In your object storage, your filesystem and your database. DocxIntel is stateless with respect to your documents beyond the processing window and holds no separate copy of its own.
Retention policy
Set entirely by you. Retention, archival and deletion follow your storage lifecycle rules, so the evidence you already produce for your regulator covers DocxIntel data without a separate vendor attestation.
Caching
No external cache of parsed documents. Intermediate artefacts live in storage you control and are cleared according to your configuration.
Residency
Determined by where you install. In-country, on-premise or fully air-gapped residency is a property of the deployment rather than a contractual promise about a region you do not control.

Control implementation for a specific release is evidenced in the security pack and verified against the deployed system during a Proof of Value, not asserted on a marketing page.

Verify, do not trust

No telemetry, no phone-home, and how to prove it yourself

Every vendor says it does not exfiltrate your data. The useful question is whether the claim is testable in an afternoon. This one is.

Test 1

Run it with egress default-deny

Apply a network policy that blocks all outbound traffic from the DocxIntel namespace, then process documents. Nothing degrades. There is no retry queue waiting for connectivity and no feature that quietly stops working.

Test 2

Put a capture on the boundary

Monitor the perimeter with your existing tooling for the duration of a Proof of Value. The expected result is zero outbound connections attributable to DocxIntel — no analytics beacon, no error reporter, no model download.

Test 3

Install with no network at all

The air-gapped deployment model is the control experiment. The bundle arrives on physical media, installs offline and produces identical output, which is only possible if nothing depends on reaching us.

How air-gapped installs work →
Mechanism

Licence activation is offline

No call-home activation, no heartbeat, no remote kill switch. Licence validation is performed locally against a signed artefact, so a network outage or a lapsed connection cannot stop document processing.

Mechanism

Models load from local storage

Weights are delivered in the bundle and mounted from local or cluster storage. No component pulls from an external model registry at runtime, so inference cannot fall back to a hosted endpoint under load.

What's in the box →
Mechanism

Diagnostics you release deliberately

Support bundles are generated locally for you to inspect and redact before sharing. Nothing is transmitted automatically, and no crash reporter or usage analytics agent is included in any image.

Build and respond

Supply chain, patching, secure development and incident response

Removing the network path handles data exposure. It does not handle the software you install, which is why the build pipeline and the patch cadence are the parts of this page worth reading twice.

Software supply chain

Image signing
Container images are cryptographically signed and published with digests. You can enforce signature verification in your admission controller so an unsigned or altered image cannot be admitted to the cluster.
SBOM
A software bill of materials is published with every release in a machine-readable format, so your own tooling can diff components and match them against your vulnerability feed before you promote a version.
Model bundle integrity
Model weights ship as checksummed bundles with published hashes, verified at install and at load. A tampered or truncated bundle fails closed rather than loading partially.
Build provenance
Images are built from pinned base layers in a controlled pipeline with build metadata retained, so a shipped artefact can be traced back to the source revision it was produced from.
Model licence transparency
Every bundled model is listed with its upstream licence and permitted use, so your legal team reviews the same list your engineers deploy.

Vulnerability handling and patch cadence

Scanning
Dependency and container scanning runs on every build, with findings triaged before release. Third-party components are tracked against upstream advisories rather than only at release time.
Patch cadence
Critical and high-severity issues in shipped components are addressed in patch releases on a published cadence within the support window. Releases are packaged for offline installation as well as connected environments.
Your upgrade window
You decide when a release is promoted. Because you control the deployment, you can assess, test against your own document set and defer under your own risk process — no forced upgrade lands in your production estate overnight.
Penetration testing
You are free to test the deployed system in your own environment without asking permission, and to share findings with us through the disclosure process below. No vendor authorisation form is required to test software running on your hardware.

Secure development

Change control
All changes go through peer review with automated static analysis, dependency checks and test gates before merge. Release branches are protected and artefacts are built only from reviewed revisions.
Separation of duties
Build, release signing and publication are separated, with credentials held in a managed secret store and access limited to named engineers on least-privilege grounds.
No customer data in development
Our engineering and benchmark work uses anonymised and synthetically generated document sets. Customer documents are never copied into our environments, which is a straightforward consequence of never receiving them.
Threat modelling
Security review is part of the design stage for new components, with the deployment threat model documented in the security pack and updated per release.

Incident response and disclosure

Where an incident occurs
Because your documents are in your estate, an incident involving them is your incident and your existing response plan governs it. We support your investigation with release provenance, log guidance and engineering assistance.
Product security incidents
A vulnerability in DocxIntel or a bundled component is communicated to licensed customers with severity, exposure conditions, mitigations and a remediation timeline, alongside a patched signed release.
Responsible disclosure
Researchers and customers can report suspected vulnerabilities through the BizfyLabs contact channel. Reports are acknowledged, triaged by severity, and we will not pursue good-faith research conducted against your own deployment.
Security pack
Architecture and data-flow diagrams, the control mapping, the SBOM, the threat model and the vulnerability-handling process are available under NDA on request through the contact link on this page.

Ask for the security pack before the Proof of Value rather than after it. Your security team reviewing week one in parallel with deployment is the difference between a 45-day evaluation and a six-month one.

Regulatory mapping

How the architecture supports your obligations

DocxIntel is not a compliance product and cannot make your organisation compliant. What it can do is remove the hardest obligation to satisfy — an external processor holding regulated documents — so the remaining work is inside your existing control environment.

Banking, UAE

CBUAE outsourcing and data residency

Central Bank of the UAE expectations around outsourcing arrangements, data residency and supervisory access are far simpler to evidence when no outsourced processing occurs. Documents are processed on infrastructure inside your own regulated estate, so your residency position is the deployment diagram and your regulator can inspect the system in place.

  • No material outsourcing of document processing
  • In-country deployment, including air-gapped
  • Supervisory inspection against your own environment
UAE PDPL

UAE Personal Data Protection Law

Cross-border transfer, processor obligations and data-subject rights all get easier when there is no processor and no transfer. Personal data stays within your controlled environment, retention and deletion run through your storage lifecycle, and access is governed by your identity provider and your RBAC.

  • No cross-border transfer to assess
  • Retention and erasure under your policy
  • Access decisions logged in your audit trail
Healthcare, UAE

UAE Health ICT Law

Health data localisation requirements are met by locating the processing, not by contracting around it. Clinical documents — handwritten prescriptions, admission forms, insurance claims — are analysed inside the facility or the payer network that already holds them, with field-level provenance available for clinical audit.

  • Health data does not leave the facility
  • Provenance on every extracted clinical value
  • Permissions-aware retrieval for clinical users
EU / UK

GDPR

Where GDPR applies, DocxIntel supports data minimisation, purpose limitation and storage limitation because you configure all three, and supports Article 15 and 17 requests through your own storage and audit tooling. There is no Chapter V transfer analysis to perform, because personal data does not leave your infrastructure.

  • No international transfer mechanism required
  • Records of processing built from your audit trail
  • Redaction available as a first-class capability
What we claim, and what we do not

Certifications: the honest position

It would be easy to put a row of framework badges on this page. We are not going to, because DocxIntel is a new product and badges we have not earned would be the least trustworthy thing on a security page.

Position

What we do not claim

DocxIntel and BizfyLabs hold no SOC 2 report, no ISO/IEC 27001 certificate and no other third-party security certification. Any vendor page implying otherwise about us is wrong, and any vendor implying it about themselves is worth asking for the report and the scope statement.

Evidence

What we do provide

Controls designed against the SOC 2 Trust Services Criteria and mapped to the ISO/IEC 27001 Annex A control set, documented in a security pack with architecture diagrams, data-flow diagrams, the threat model, the SBOM and the vulnerability-handling process. Available under NDA on request.

Request the pack →
Scope

How this supports your own audit

Because DocxIntel runs inside your environment, it falls within the scope of the certification you already hold rather than requiring you to inherit assurance from us. Your access controls, encryption, logging, change management and retention evidence apply to it directly — which is a stronger position than a vendor attestation about a system you cannot inspect.

Questions a CISO asks first

Direct answers, including the ones where the answer is no.

No, and we will not imply otherwise. DocxIntel is a new product and holds no third-party security certification. What we do is build and document controls designed against the SOC 2 Trust Services Criteria and the ISO/IEC 27001 Annex A control set, and ship a system that runs entirely inside your certified environment — so the platform sits within the scope of your certification rather than asking you to inherit ours. The security pack, including the control mapping, is available under NDA on request.

Empirically, which is the only verification worth having. Deploy into a namespace with a default-deny egress policy, put a capture on the network boundary, and process documents for as long as you like. There is no outbound call to make: licence activation is offline, model weights load from local storage, there is no crash reporter and no usage analytics. A fully air-gapped install performs identically to a connected one, which is the strongest evidence that nothing depends on reaching us.

You do, in every deployment model. DocxIntel integrates with your KMS or HSM for data-at-rest keys and uses your PKI for transport certificates; it does not generate, escrow or transmit key material, and BizfyLabs holds no copy. Key rotation follows your policy and your schedule. There is no vendor-side envelope key, because there is no vendor side.

Container images are scanned on every build and an SBOM is published with each release, so you can diff component versions against your own vulnerability feed before promoting a release. Critical and high-severity issues in shipped components are addressed in patch releases on a published cadence, delivered as signed images with checksums and packaged for offline installation as well as connected ones. Because you control the upgrade window, you can also assess and defer a release against your own risk process.

Whatever you configure, and nothing by default that you have not asked for. Documents, extraction output, audit logs and review history all live in your own storage under your own retention policy and your own backup regime. There is no vendor cache, no 48-hour parsed-data retention and no staging bucket outside your perimeter. Deletion is a function of your storage lifecycle rules, which means your existing retention evidence covers it.

Support is designed for environments where remote access does not exist. Diagnostics are generated locally as a bundle you inspect and redact before sharing, log and metric exports are yours to release or withhold, and upgrade runbooks are written for offline installation from physical media. Where your security team does approve a supervised access path, we use it; where it does not, the support model still functions.

Keep reading

Deployment models→Air-gapped, private cloud, managed single-tenant and evaluation sandbox topologies.What's in the box→Every container, model bundle and dependency your security team will be reviewing.Model licences→The open-weight models shipped in the bundle and the licence terms attached to each.Reference architectures→Network, storage and identity layouts for regulated single-site and dual-site estates.Proof of Value→How your security team reviews the deployed system during the evaluation window.Pricing→Why the licence is fixed annually and why air-gapped operation is not a premium tier.

Ask for the security pack.

Architecture and data-flow diagrams, the control mapping, the threat model, the SBOM and the vulnerability-handling process, available under NDA. Send it to your security team before the Proof of Value, not after.

Request the security pack
See deployment models
  • No egress, no phone-home
  • You hold the keys
  • Reviewed against the deployed system
DocxIntel Logo

A product of BizfyLabs

Document intelligence that never leaves your building. Analyse, identify, classify, map, modify and ask — inside your own infrastructure.

BizfyLabs on LinkedInDocxIntel documentationBizfyLabs

Product

  • Capabilities
    • Analyse
    • Identify
    • Classify
    • Map
    • Modify
    • Ask
  • Accuracy benchmark
  • Pricing
  • Proof of Value

Technical

  • Deployment models
  • Reference architectures
  • Sizing & throughput
  • What's in the box
  • Security posture
  • Model licences
  • Documentation
  • API reference

Solutions

  • All industries
  • Insurance & TPAs
  • Healthcare
  • Banking & finance
  • Government
  • Legal
  • Energy & logistics

Compare

  • Compare approaches
  • LlamaParse alternative
  • Docsumo alternative
  • On-premise document AI

Company

  • About DocxIntel
  • FAQ
  • Partners
  • BizfyLabs
  • Careers
  • Contact

© 2026 BizfyLabs FZC LLC. All rights reserved.

DocxIntel™ is a product of BizfyLabs FZC LLC.

  • Privacy Policy·
  • Terms of Service·
  • Data Processing Addendum·
  • Acceptable Use·
  • Model Licences·
  • Security·
  • Cookies

Registered in the United Arab Emirates. Delivery partner: Bizfy Solutions LLP, Indore, India.

DocxIntel