Search

What are you looking for?

Search our services, use cases and practical insights.

Enter at least 2 characters

Popular starting points

Use business data responsibly with AI

AI does not process questions alone. It often handles documents, personal data and internal knowledge. This area explains where that data goes, which commitments matter and how organisations can exercise accountability in practice.

Data & governance

Privacy in AI is not a single product setting. The purpose, full data flow, participating providers and controls inside the organisation determine what is appropriate. These articles turn provider terminology into questions that support a defensible decision.

After this area, you can assess

  • which data an AI application actually processes and where additional storage can arise

  • why training, retention, data location and Zero Data Retention are separate commitments

  • which contractual, technical and organisational evidence matters when assessing a provider

  • how to introduce and operate an AI use case with clear rules for business data

  • which AI literacy different roles need for safe and effective use

Questions for handling business data

These questions connect a technical term to a concrete organisational decision.

  • Which data does the task genuinely require, and which data should never reach the AI system?

  • Which providers, subprocessors and downstream systems can access or retain content?

  • How are training, retention, regions, deletion and support access governed?

  • Who approves use, monitors change and responds to incidents?

Articles

What happens to business data when we use AI?

An application receives business data, may add further context and sends the resulting content to an AI model for processing. Whether inputs and outputs are then logged, retained, used for other purposes or passed to additional services depends on the product, configuration and contractual terms.

  • Processing, retention and model training are separate activities and need separate assessment.
  • The processed data can include documents, system instructions, search results and metadata in addition to the visible prompt.
  • Connectors, web search and business systems extend the data flow beyond the model itself.
Read article

What does Zero Data Retention (ZDR) mean – and what does it not guarantee?

Zero Data Retention is a contractual or technical rule under which covered customer content is not retained persistently after processing by covered features. The content still has to be processed, and ZDR alone says nothing conclusive about training, metadata, data location, third parties or features outside its scope.

  • ZDR is not a uniform legal or industry standard; each provider defines its exact meaning.
  • The commitment often applies only to certain accounts, projects, models, APIs and features.
  • No persistent content retention does not mean no processing, no metadata or no third parties.
Read article

How do you assess privacy and data processing at an AI provider?

Assess an AI provider at four levels: the full data flow of the exact product, legal roles and contractual terms, technical and organisational safeguards, and evidence that those safeguards apply to your real configuration and ongoing operation.

  • Start with the task, data and consequences of error, not a generic vendor questionnaire.
  • Assess the exact plan, endpoint and feature set; statements about the brand alone are too broad.
  • Separate training, retention, data location, subprocessors, support access and internal logging.
Read article

Data classification for AI: Which company data may employees use?

Employees should enter only the data needed for the task and permitted by the company’s data classification for that specific approved AI tool. Personal data, trade secrets, credentials and particularly sensitive content require explicit approval or must not be entered at all.

  • Permission depends on the data class, purpose, tool, contract and configuration.
  • A company account does not automatically make every input safe or lawful.
  • Outputs, embeddings, logs and evaluation data generally inherit the protection of their sources.
Read article

No training, no storage or data residency: What is the difference?

No training limits the use of customer data to improve models, no storage concerns the retention of content, and data residency designates regions for certain processing or storage. None of these promises automatically includes the others.

  • Training, storage, processing, deletion and location are separate properties.
  • Scope may vary by product, plan, endpoint and feature.
  • Operational and billing metadata can exist even without content retention.
Read article

What does AI governance mean in a company?

AI governance is the system of accountabilities, decision paths, rules and evidence by which an organisation manages the value and risks of AI applications throughout their lifecycle.

  • Governance connects business objectives, law, security, technology and domain accountability.
  • The effort should match the impact and risk of the use case.
  • An inventory, clear roles and evidence-based approvals form the operational foundation.
Read article

What should an internal AI policy contain?

An internal AI policy defines who and what it covers, which tools and data are allowed, which human checks are required and how new applications, changes and incidents are handled.

  • The policy must be short enough for daily use and precise enough for real decisions.
  • Approved tools and data classes need a maintained, easy-to-find list.
  • Obligations depend on impact: a draft, recommendation and automated action are not equivalent.
Read article

AI literacy in companies: Who needs to understand what?

An effective AI literacy programme assigns concrete learning objectives, exercises and evidence to each role. Ordinary users need safe-use rules, domain reviewers must assess results and sources, accountable owners must govern risks and approvals, and technical teams must develop and operate systems safely. The required depth depends on the task, system and potential impact.

  • An introductory module creates a shared foundation; role- and application-specific learning paths make it practical.
  • Real work cases and observable tasks demonstrate more than a certificate of attendance.
  • Onboarding, new systems, model or policy changes and incidents trigger learning or refreshers.
Read article

Which AI systems, roles and accountabilities should a company track?

An AI inventory is a maintained record of AI systems in use, testing and procurement. Each entry documents its purpose, users, data, providers, risk tier, status and named business and technical owners.

  • The inventory also covers AI features in existing business software and active pilots.
  • A product name is insufficient; purpose, configuration and data flow are what matter.
  • Roles must cover decisions and operation, not just the project phase.
Read article

When does an AI project need a data protection impact assessment?

Under Swiss data protection law, a DPIA is required where planned processing of personal data is likely to result in a high risk to the personality or fundamental rights of data subjects, subject to the narrow statutory exceptions available to private controllers. The nature, scope, circumstances, purpose and technology of the specific processing determine the assessment.

  • The DPIA question arises only where personal data is processed, but should then be asked early.
  • New technology alone does not automatically trigger a DPIA, although it may increase risk.
  • A DPIA describes the processing, risks, safeguards and remaining risk.
Read article

What does the EU AI Act mean for Swiss companies?

A Swiss company should assess the EU AI Act particularly where it places an AI system or general-purpose AI model on the EU market, acts as a covered provider or deployer, or where output from a system operated outside the EU is used in the EU. Applicable duties depend on role, system, purpose, market connection and application date.

  • A Swiss registered office does not rule out application of the EU AI Act.
  • The Act distinguishes four system risk levels: unacceptable, high, transparency, and minimal or no risk.
  • Classification follows the intended purpose and context; the same model can support systems in different risk levels.
Read article

How should data locations, subprocessors and international transfers be assessed?

For each data type, an organisation should document who processes it, for what purpose, where storage and processing occur and which subprocessors are involved. Where personal data is disclosed abroad, adequacy, appropriate safeguards and remaining risks must also be assessed under Swiss law.

  • Data location should be assessed separately for storage, processing, support and metadata.
  • The primary provider is not the only recipient; subprocessors and optional services count too.
  • A region setting does not by itself establish that an international transfer is lawful.
Read article

What happens to data and configurations when a contract ends or a provider changes?

Before a contract ends, the organisation should know which data and configurations can be exported, how long access remains, how migration and continuity will work, and how the provider and its subprocessors will delete remaining copies. Technical and organisational completion should be verified.

  • Exit requirements belong in architecture and contracts before signing.
  • Prompts, configurations, permissions, tests and logs are as relevant as documents.
  • Exportability does not mean another system can use the format without adaptation.
Read article

What rules apply to automated decisions and human review?

Swiss data protection law provides specific information and review rights where a decision is based exclusively on automated processing and produces a legal effect or similarly significantly affects the data subject. Whether this test is met and which exceptions apply must be assessed for the actual process.

  • Exclusive automation and significant effect matter, not the label AI.
  • A formal click approval is not effective human review if it merely rubber-stamps the output.
  • Affected people need understandable information and a genuinely usable review route.
Read article

How should an AI-related data protection incident be handled?

An AI-related privacy incident should be contained, documented and assessed immediately based on the data, people and possible consequences involved. Under Swiss law, the controller must notify the FDPIC as soon as possible where a breach is likely to result in a high risk to the personality or fundamental rights of data subjects; communication to affected people is assessed separately.

  • Incorrect output and security incidents are different, although they can overlap.
  • Prompts, responses, tool calls and permissions are important evidence.
  • A processor informs the controller as soon as possible; the controller assesses risk and makes the statutory notification decision.
Read article

Put a concrete initiative into perspective.

We translate your starting point into understandable options and a realistic next step.

Discuss Your Project