AI integration in Switzerland
An assistant that finds your documents, information extracted for review, or help connected to your CRM: we integrate AI around a specific task. We also assess local and private deployments so you can retain control over data and day-to-day operation.
Practical uses
We start with a task and the people doing it. A pilot tests whether AI offers useful assistance, with errors and costs that are acceptable for that use.
A document assistant searches authorised material, then drafts an answer with references. This approach, called retrieval-augmented generation or RAG, combines generation with document search. The application continues to enforce reading permissions.
Prepare fields from an enquiry, classify a document or suggest a summary for review. We define the expected formats and the cases a person must check before information enters your business software.
Find a record, prepare notes or propose an update through your existing tools’ APIs. Available operations are explicit. A consequential change follows the approval step agreed for your workflow.
An assistant can suggest a next step and request functions defined in the application. The server checks each request. The model does not receive broad access to your files, accounts or systems.
Local AI and data sovereignty
Control depends on architecture, access and contracts. We examine the full data journey. A server in Switzerland or a locally installed model does not, by itself, guarantee confidentiality or compliance with every applicable obligation.
Understand data controlThe selected model and components run on your equipment or private network. This can suit work that must stay within an environment you administer. Hardware capacity, backups and responsibility for operation still need to be planned.
Infrastructure chosen with you can host the model, document search and application. We review processing locations, administrative access, subcontractors and service terms. Operational responsibilities and the ability to retrieve your data are defined.
Some processing stays local; other tasks can use an approved external service. We define which information may leave, which provider receives it and under what conditions. Any switch to another service must follow an agreed, documented rule.
Control across the system
For a local deployment, we also review the components that prepare, search, record and back up information. Users and operators need a clear account of the system’s boundaries.
The data journey covers document import, splitting into passages, the numerical representations used for search — embeddings — and their index. We define where each is calculated and stored, who can access it and how deletion is propagated.
Requests, answers, histories and logs can contain sensitive information. We define what is recorded, how long it is retained and who may access it. Backups, monitoring tools and any telemetry sent elsewhere receive the same scrutiny.
We identify the models, libraries, connectors and services the application needs. Their licences must fit the intended use. Cloud features, web search and outbound connections are reviewed; updates are tested before deployment.
Sizing depends on the model, document length, concurrent users and required response time. The pilot measures these constraints. The budget also covers storage, backups, monitoring, maintenance and any external API consumption.
Quality and security
An answer can be wrong even when it sounds convincing or includes a reference. We choose controls around the consequences of an error, then test representative tasks and attempts to misuse the system.
The pilot includes questions with expected answers, incomplete documents and cases where no answer is available. We assess errors and proposed references. When evidence is missing, the interface needs a way to say so and let the user return to the source.
A document can contain instructions intended to redirect the assistant: prompt injection. We separate retrieved content from application commands, restrict available tools and test those boundaries. A model instruction cannot replace server-side permission checks.
Sending a message, changing a record or triggering an operation requires suitable permissions. The application checks outputs, with human approval at agreed stages. One user’s data must not become available to another through the assistant.
If the model is unavailable or its output cannot be used, people need a search, entry or manual-review path. We prepare usage limits, useful alerts and a procedure to disable a feature or return to a previous version.
Our approach
Each stage produces something to review together. A production release depends on the pilot results, accepted risks and readiness to operate the service.
Explore our methodChoose the task, users and permitted data. Identify connected systems, processing constraints and the criteria that will make the result useful.
Build a limited version with representative test cases. Compare quality, errors, response time and cost, then decide whether to continue, adjust or stop.
Develop the user journey, connectors and server-side checks. Test permissions, approvals and error handling with the people involved.
Check configuration, access and backups. Document installation and recovery, prepare users and approve the scope being released.
Review feedback, errors and consumption. Retest changes to models, data and connectors, and agree the next improvements.
Defined deliverables
We agree the precise deliverables during scoping. They should help you understand the system, control its use and prepare for maintenance.
Selected uses, data, processing locations, providers and responsibilities. Access, retention and external dependencies are explained.
Cases tested, acceptance criteria, observed results and remaining errors. The limits of the evaluation set accompany the decision about the next stage.
The agreed workflow, connectors, permissions and approvals. Users receive guidance on permitted data, checking answers and reporting errors.
Configuration, versions, access to hand over, backups and recovery procedures. Ownership, licences and handover arrangements are specified in the contract.
Alongside existing software
An AI feature can extend an internal application, a portal or a SaaS product. We examine the APIs, permissions and data quality before defining the changes needed.
The assistant needs a clear place in a task: consult, propose, check, then approve. We can integrate that journey into custom software or prepare a dedicated interface around the constraints of your existing application.
Explore custom applicationsInput rules and account type matter alongside the interface. Our article on personal ChatGPT accounts at work helps start the discussion about which information may be shared.
Read about ChatGPT use at workFrequently asked questions
We can discuss these points in an initial conversation and make them specific during scoping.
Yes, when the model and every required component can run within your environment. That includes document search, embeddings, authentication, logs and backups. An objective of using no external service requires checks on outbound connections, cloud features, installation and updates. Hardware needs and achieved quality are assessed during the pilot.
It means defining the control you retain: processing locations, access, providers, licences and the ability to export data and take over the system. Local or Swiss hosting creates no automatic legal guarantee. Applicable obligations and contracts need to be reviewed with the people responsible for your organisation.
Not necessarily. Document retrieval can supply useful passages for a request without changing the model’s parameters. It still requires document preparation, access management and evaluation. Additional training is considered only when a defined need and suitable data justify it.
Yes. Retrieval may miss a passage, and the model may misinterpret it or produce incorrect information. References help people check an answer; they do not guarantee it. We define which cases require human review and when the assistant should explain a limitation or hand the task back.
We estimate them after scoping. The task, document quality, connectors, hosting, hardware and operational requirements all affect the work. A pilot gives an initial stage that can be priced, then helps refine the integration. Recurring costs and human-review time belong in the estimate too.
We agree who monitors the service, handles incidents and approves updates. Support can cover connectors, documents, models and regression tests. Access, responsibilities and the maintenance scope are agreed before release.
Have an AI use in mind?
Tell us what your team needs to do, which tools you already use and what data is involved. We can identify the first decisions and define a pilot’s scope.
