On-Premises Anonymization

No external document processing - Detection, extraction, OCR, anonymization and document reconstruction take place on-premises or inside a private environment under your control. The API does not require source content to be transmitted to a third-party AI or cloud service.

No data or telemetry sent to GenerIA - Once deployed, the API operates without transmitting any data or telemetry to GenerIA. GenerIA therefore has no visibility into your workloads or service activity. Any information shared with GenerIA for support or analysis requires a separate, deliberate action authorized by you.

A protective gateway for other systems - The API can anonymize data and documents before they are shared with partners, transferred between environments, added to test datasets, used for analytics or submitted to internal or external AI applications. Existing workflows are not modified but reduce unnecessary exposure of sensitive data.

Anonymization or pseudonymization according to purpose - The service can remove, mask or generalize detected identifiers when maintaining a link to the same entity is unnecessary, or replace them with pseudonyms when continuity across documents and records is useful. Depending on the use case, the same entity may retain a consistent pseudonym within a document, across a batch or throughout a deployment, or receive different pseudonyms to prevent correlation between contexts. Pseudonyms may take the form of technical identifiers or realistic synthetic values. A controlled re-identification mechanism can be retained when required, or omitted when the workflow does not need one.

Governance remains yours - Your organization decides where the service runs, who may call it, which entity categories are processed and how source and output files are retained. Authentication can be enforced through API keys, while surrounding network and access policies remain those of your infrastructure.

Support for privacy and data-minimization obligations - Local anonymization and pseudonymization supports privacy-by-design, confidentiality and data-minimization processes under frameworks such as Loi 25, GDPR and comparable regulations. The two approaches should not be confused: anonymization aims to prevent re-identification in practice, whereas pseudonymization replaces identifying information while allowing attribution through separately held additional information. Pseudonymized data therefore remains personal data and continues to be governed by applicable privacy requirements. Either approach contributes to compliance but does not replace the organization's assessment of re-identification risk, lawful purpose, retention, access controls and other governance obligations.

Traceability without external disclosure - Each response exposes an X-Request-ID that can correlate user-visible results, application activity and support investigations. Operational information remains available to your teams without requiring document content or telemetry to be exported to an external platform.

Standard business documents - Supported formats include PDF, TXT, Microsoft Word, Excel and PowerPoint documents, including current Office Open XML formats. Processing is format-aware so that sensitive information is removed without reducing every source to unstructured plain text.

Regenerative PDF redaction - When sensitive content is detected, PDF outputs prioritize document regeneration rather than placing a visual mask over recoverable text. The objective is to remove the underlying information from the resulting content, not merely conceal its appearance on the page.

Office content beyond the visible page - Word comments, Excel comments and hidden sheets, PowerPoint speaker notes and classic or modern Microsoft 365 comments are processed alongside the main document text. Common OOXML document metadata is sanitized, and sensitive hyperlinks are removed where applicable.

Complete EML processing - Sensitive email headers and both plain-text and HTML message bodies are anonymized. Supported attachments are processed individually, with PDF attachments passed through OCR when necessary, before the EML message is reconstructed for continued use or archiving.

ZIP, TAR and TAR.GZ archives - Supported files contained in an archive are processed while its internal directory structure is retained. Unsupported internal files are copied unchanged, allowing heterogeneous operational packages to be handled without dismantling and rebuilding them manually.

Multilingual entity detection - French, English and Spanish are supported today, with French used by default when no language is supplied. More languages can be added to the list upon demand. The requested entity categories can be explicitly selected by language for each operation.

Configurable protection and replacement strategies - Callers may use the language-specific default mask, provide custom replacement text or request pseudonyms in the form of technical identifiers or realistic synthetic values. Pseudonym consistency can be scoped to a document, a batch or the complete deployment, while controlled re-identification can be enabled when required. Callers may also override the output filename, while the service ensures that the final extension remains consistent with the actual document type.

Two deployment variants - A GPU-enabled version is available for infrastructures that require acceleration and sustained processing capacity. A CPU-only version supports organizations, isolated environments and workloads for which dedicated GPU hardware is unavailable or unnecessary.

One principal endpoint - Applications submit a source file to POST /v1/documents/anonymize. Optional form parameters select the processing language, entity categories, replacement text, output filename and so on, keeping the minimal request extremely simple while supporting more controlled integrations.

Scriptable batch processing - Because the API is accessible through standard HTTP calls, it can be driven by lightweight Bash or other command-line scripts. A single command can traverse an entire directory and its subdirectories, submit every supported file for anonymization and save the resulting documents. This provides a straightforward way to process complete document collections, automate recurring batches or integrate anonymization into scheduled tasks and existing file-processing pipelines without developing a dedicated application.

Included web interface - Users can drag and drop a document, enter an API key when required, select the processing language, launch anonymization and download the result directly. The interface also displays processing status and the latest X-Request-ID for support and correlation.

Self-documented integration - In addition to the OpenAPI JSON definition, Swagger UI and ReDoc documentations are available with the service, directly from the Web interface. They are designed to reflect all updates to the service, including bespoke ones. Development teams can therefore inspect the contract, integrate clients and test requests without depending on separate or potentially outdated documentation.

Compatible with existing workflows - The HTTP API can be called from business applications, document pipelines, ETL processes, RAG ingestion chains, AI gateways, file-processing workers and automated compliance workflows. The product provides anonymization and pseudonymization capabilities without imposing a new user-facing application.

Infrastructure choices remain open - The containerized service can run on your servers, in private data centers, in sovereign hosting environments or on other Docker-compatible infrastructures. Network exposure, TLS termination, access control, storage and monitoring remain adaptable to your strategies.

Useful results when nothing is detected - A document containing no detected sensitive entity is still returned under the expected output name. Depending on the format, artifacts like metadata, annotations, widgets, embedded files or other document-level objects are sanitized without unnecessarily regenerating otherwise unchanged content.

Controlled partial-success behavior - Email attachments and archive members are processed individually. Configurable best-effort policies keep the processed package usable when a supported internal item cannot be transformed, while response metadata makes the partial outcome visible rather than silently presenting it as complete success.

Structured status information - EML responses report processing status together with the numbers of attachments processed, failed or skipped. This allows a calling application to decide whether the output can proceed automatically, requires review or should be rejected according to its own policy.

Explicit HTTP errors - Standard responses distinguish successful processing from missing authorization, excessive file size, unsupported media types, invalid parameters, unprocessable documents and unavailable instances. The included web interface presents the returned HTTP message directly to assist testing and support.

Output naming that applications can trust - Default names follow the original filename with an .anonymized marker, including preservation of the double extension for TAR.GZ archives. A custom output name remains a simple filename, and its extension is aligned with the real output format.

Liveness and readiness endpoints - GET /health reports basic HTTP-process liveness, while GET /health/ready verifies operational readiness before an instance receives traffic. Readiness checks cover the document pipeline, expected OCR dependencies and log-sink write capability.

Suitable for supervised scaling - Health endpoints, request identifiers and containerized packaging make the service compatible with load balancers and container supervision. CPU and GPU deployments can be sized and replicated according to document volume, format distribution and latency objectives.

Ready-to-use standard edition - Organizations whose needs match the supported languages, formats and entity categories can deploy the packaged product directly. The Docker delivery model reduces installation work and makes evaluation, acceptance and production rollout straightforward. Typically, the platform is operational within a day.

Specialized entity detection - Detection can be optimized for domain-specific identifiers, terminology or sensitive information that generic entity categories do not represent adequately. Representative data and expert validation provide the basis for measuring the improvement.

Additional document formats - New parsers and reconstruction components can be developed for proprietary or industry-specific files. The same principle applies when a nominally standard format contains uncommon embedded objects or processing requirements.

Document-structure specialization - Repeated layouts, forms, reports, correspondence and structured document families are handled through targeted extraction and validation logic. Structure-aware specialization improves detection while limiting unnecessary changes to surrounding content.

Workflow-specific behavior - Output policies, entity selections, strict or best-effort handling, authentication, logging and integration behavior can be adapted to the your risk model and downstream applications.

Fast evolution without losing product simplicity - Specialization extends the maintained product rather than replacing it with an unrelated custom application. Your have the same containerized deployment model, API principles, operational interfaces and documentations while receiving the capabilities required by your use cases.

Format identification and validation - The service validates incoming media types, extensions and processing parameters before dispatching content to specialized handlers. File-size limits and explicit rejection paths prevent unsupported or malformed inputs from entering ambiguous processing states.

Layered sensitive-entity detection - Multilingual Named Entity Recognition can be combined with deterministic patterns, configurable entity selections and format-specific context. This layered approach balances coverage and precision instead of relying on a single universal detector for every kind of sensitive information.

Consistent pseudonym generation and protected re-identification controls - Pseudonymization policies independently control the replacement format, the scope of consistency and the availability of controlled re-identification. The pipeline can preserve a stable relationship for the same entity within a document, across a batch or throughout a deployment, or deliberately generate unrelated pseudonyms between contexts. When controlled re-identification is enabled, the additional information required to restore authorized identities is isolated from the processed content and protected through dedicated access controls and audit trails. When it is not required, no service-managed correspondence mechanism needs to be retained. This flexibility preserves the analytical and operational value of the data while limiting identity exposure and unwanted correlation.

OCR-aware document processing - PDFs without usable extractable text are passed through the platform's advanced OCR pipeline, including when they appear as email attachments. Readiness checks verify that the required OCR dependencies are available before the instance is placed into service.

Regenerative content rewriting - For sensitive PDF text, the pipeline prioritizes content reconstruction over superficial visual covering. Office and text outputs are rewritten through format-aware mechanisms that preserve their intended usability while replacing detected information.

Office package sanitation - DOCX, XLSX and PPTX files are processed as structured OOXML packages. Relevant body content, comments, hidden content, notes, hyperlinks and document properties are handled according to the capabilities and policies defined for each format.

MIME-aware email reconstruction - EML processing traverses headers, multipart bodies and attachments according to their MIME structure. Supported attachments are anonymized through their own handlers before the complete message is reconstructed with explicit processing metadata.

Archive-safe traversal - ZIP, TAR and TAR.GZ packages are unpacked inside controlled processing boundaries. Supported members are transformed, unsupported members are handled according to policy and the internal directory structure is reproduced in the resulting archive.

Metadata and embedded-artifact sanitation - Anonymization includes relevant information outside the visible document body. Common Office properties, PDF metadata, annotations, widgets, embedded files and sensitive hyperlinks are sanitized or removed according to the output format.

Controlled failure semantics - Strict failures, skipped items and partial successes are represented explicitly. The pipeline prevents a recoverable attachment problem from being confused with complete processing while allowing your policies to determine whether a best-effort result is acceptable.

CPU- and GPU-aware execution - Separate product variants package the appropriate runtimes and processing components for CPU-only or GPU-enabled servers. Profiling, concurrency controls and resource limits can be tuned to your document mix and throughput objectives.

Health, logs and request correlation - Liveness, operational readiness and per-request identifiers expose the state needed by supervisors, load balancers and support teams. Logging remains inside the controlled environment and can be integrated with your existing observability systems.

Testable anonymization quality - Representative documents, multilingual entity sets, OCR cases, nested content and malformed inputs can be maintained as versioned evaluation suites. Detection quality, document integrity, regressions, latency and resource use are assessed together before a specialized version is released.