How Counterfold is deployed.

01 / Begin with the decision

We first define the operational question, intended users, source systems and decisions the software would support. Together, we identify a measurable first workflow and the people responsible for its data, security and acceptance.

Discovery produces a data map, intended-use assessment, proposed architecture, responsibility schedule and costed pilot scope. A signed discovery does not automatically authorise access to sensitive data or production operation. Each phase has its own entry conditions and acceptance evidence.

The same foundation can connect authorised evidence, employee agents, management analysis, approved actions and organisational decision memory. Permissions and intended-use limits apply across the whole suite, including derived briefings and executive agents.

02 / Choose who controls the environment

Our preferred starting pattern is a dedicated deployment in the client’s approved cloud account or private infrastructure. Client-controlled can mean an approved AWS account or Google Cloud project; it does not require servers in the client’s building. Infrastructure, application and support responsibilities are assigned explicitly.

A dedicated environment operated by Counterfold or an approved specialist partner can also be scoped. This requires agreement on the operator, service coverage, supplier contracts, data locations and any necessary authorisations. These options are assessed per engagement; no cloud brand or partner is selected by this page.

For sensitive work, the proposed design separates clients and separates development, testing and production. Existing systems remain the source of record where practical. Only the records and derivatives needed for the agreed workflow are introduced into the deployment.

03 / Decide where AI processing happens

Private inference: an appropriately licensed model runs inside the approved private environment. Retrieval, embeddings, document processing and operational logs must fit the same boundary. This option still needs model-quality testing, capacity, patching and recovery.

Approved managed inference: a selected enterprise model service processes an authorised payload through approved endpoints. We assess the exact model, region, routing and failover, retention, human review, training terms and enabled features. AWS and Google are possible providers, subject to that assessment. A private network connection does not make the model run inside the client’s account.

Split processing: sensitive retrieval and calculations remain private, while an approved reduced payload goes to a permitted model. Redaction must be tested; replacing a name does not necessarily anonymise the record. A blocked request must not silently fall back to another model or region.

EU storage, no use for training and zero retention describe different properties. Search grounding, caches, agent memory, evaluations, support and monitoring can create additional data flows. Those features require their own approval.

04 / Make support access explicit

The proposed support process starts with health metrics and sanitised diagnostics. If resolving a problem requires client content, a named person requests access for a specific ticket, purpose, scope and time window. The client grants the agreed limited privileges, with strong authentication and an auditable session.

Work stays in the approved environment. Any export requires a separately approved destination, protection and deletion plan. Temporary privileges expire or are revoked at closure, and the client can review the access record.

Emergency access requires a pre-agreed incident procedure, defined responders and prompt notification. It is not a standing right to inspect all records. Cloud and model providers’ own administrative or legally required access is assessed separately; our approval process does not automatically govern their personnel.

05 / Account for every copy

The data schedule covers source extracts, indexes, embeddings, prompts, outputs, decision memory, audit records, support material and backups. It identifies purpose, location, access, retention and deletion for each category. There is no general promise that the application stores nothing.

Source permissions must also protect derived answers and summaries. Removing access or withdrawing a source requires a defined propagation process. Training or adapting a model on client content requires a separate instruction, evaluation and lifecycle plan; removing a document from retrieval does not erase it from trained weights.

Exit planning begins during design: export formats, configurations, authorised decision records, transition support and licence dependencies are documented. Deletion records distinguish live removal, backup expiry and lawful retention. Restored backups must not reintroduce records that should have been deleted.

06 / Match assurance to the actual use

Data protection, business confidentiality, cybersecurity, sector rules and procurement requirements are assessed together. Hosting data in Europe does not by itself establish GDPR compliance. Processing roles, legal grounds, contracts, international access and technical measures also matter.

Finance can require DORA arrangements, secrecy controls and a Luxembourg operating-authorisation review. Healthcare adds health-data and possible medical-device questions. Public institutions add procurement, classification and public-law requirements. Aviation adds assessment of safety-related information-security risks. NIS2 and AI rules depend on the organisation and intended use.

The engagement records applicable requirements and evidence before sensitive processing or production. Counterfold does not claim ISO 27001 certification or a SOC 2 report on this page. Supplier certificates describe their own scope and do not certify our application. Independent assessment and certification requirements are agreed with the client.

07 / Prove the workflow before expanding it

The first pilot should have a limited dataset, defined users, a baseline and acceptance measures agreed before testing. A historical or read-only workflow can establish useful evidence while production dependencies are resolved.

Acceptance covers task quality and numerical accuracy as well as source permissions, isolation, model routing, tool authority, prompt-injection resistance, deletion and recovery. We document limitations and unresolved findings. Public demo role selectors are simulations, not evidence of production authentication.

Production requires explicit acceptance, an operating team, incident contacts, achievable service levels and any required approvals. Material changes to models, suppliers, data or intended purpose return to review. Human owners retain the decisions assigned to them; an agent’s recommendation does not grant permission to execute it.