No vendor lock-in

Our thesis has two halves. On the model: “We guarantee the capacity, not the provider.” On your data: it’s yours, always, and you can take it with you whenever you want. Lock-in (getting trapped in a platform because leaving costs too much) is a design decision, and at Shara we’ve decided the opposite. This page explains, with no fine print, why you don’t stay captive with us.

When someone fears getting trapped in a tool, they actually fear two different things. Worth separating them because they have different solutions:

• Model-provider captivity. That the platform ties you to whichever AI engine is in use, and that if that provider raises the price, degrades quality or leaves the EU, it becomes your problem. We solve it with model aliasing.
• Data captivity. That your information ends up locked inside the platform in a proprietary format, so leaving means starting from scratch. We solve it with open export and real portability.

Neither is a favour we’re doing you: they’re contract clauses and verifiable technical decisions. If one day we stop convincing you, we want the exit door to be open and well signposted.

Your company always talks to four public models. The real provider behind each alias is irrelevant to your day-to-day and changes whenever a better one appears, without your team touching anything.

The real provider behind each alias is confidential under NDA. Max and Concerto Local clients can sign a specific NDA if they need it for compliance.

• No mandatory migrations: your prompt works today and in a year.
• No negotiating with a third party: you renegotiate only with AIGiner, not with each provider.
• No regulatory surprises: if a provider changes its data policy or leaves the EU, we migrate without your team ever knowing.
• Consistent capacity across plans and over time.

• Capacity continuity: replacement with a model of equal or higher performance, at no cost.
• No silent degradation: 30 days’ notice if the quality behind an alias were to drop.
• Internal traceability: every call logs which alias was used and what cost it generated.

Let’s start with what matters: ownership of your data doesn’t change by using Shara. You remain the data controller; we act as data processor on your behalf, under GDPR and the data processing agreement (DPA) you sign when activating the account. We don’t sell your data, don’t use it to train models and don’t mix it with other clients’ data: multi-tenant isolation keeps it separated at all times.

We consider yours and exportable everything you’ve put or generated inside the platform:

• Your corporate identity (IDENTITY.md): tone, values, rules and its patch history.
• The conversations with Amadeus and with each departmental agent.
• The drafts, proposals and deliverables produced by the agents.
• The full audit log (who asked for what, which agent resolved it, before and after every action).
• The configuration: active agents, departments, roles, team members and schedules.
• The historical STU consumption and the billing detail.
• The list of linked connectors (references and metadata, never your passwords, which we never see).

All the data infrastructure lives in the EU. Export isn’t an exceptional procedure you have to justify: it’s a product feature, available whenever you want.

You can request a full export of your workspace at any time, with no advance notice and no conditions. It’s generated from the panel, at Settings → Data, and doesn’t require talking to sales or explaining why. It’s your GDPR portability right, turned into a button.

1. An administrator goes to Settings → Data → Export workspace (requires an admin role and two-step verification).
2. You choose the scope: the whole workspace, or just one domain (conversations, audit, identity, billing).
3. Shara generates a .zip package with files in standard formats and lets you know when it’s ready.
4. You download the package from a single-use link with an expiry. That’s the end of it: the data is yours and you already have it out.

Every export includes a manifest describing what it contains and in what format, so you know exactly what you’re taking with you:

{
  "export_id": "exp_7c4a91f2",
  "tenant_id": "wksp_3f9a2c",
  "generated_at": "2026-07-11T09:42:15Z",
  "scope": "full",
  "format": "zip",
  "region": "eu",
  "contents": [
    { "file": "identity.md",         "format": "markdown" },
    { "file": "identity_history.jsonl", "format": "jsonl" },
    { "file": "agents.json",         "format": "json" },
    { "file": "conversations.jsonl", "format": "jsonl" },
    { "file": "drafts/",             "format": "markdown" },
    { "file": "audit_logs.jsonl",    "format": "jsonl" },
    { "file": "usage.csv",           "format": "csv" },
    { "file": "connectors.json",     "format": "json" }
  ],
  "expires_at": "2026-07-18T09:42:15Z"
}

If you’d rather not operate from the panel, any administrator can request the export in writing at privacy@aiginer.com. We deliver it in the same open format and within the timeframes set by GDPR.

There’s no file encrypted with a key only we have, and no binary format that only Shara can read. Everything comes out in formats any tool, script or person can open:

We chose JSON, JSONL, Markdown and CSV on purpose: they’re open, plain-text and widely supported formats. Nothing you take with you depends on Shara continuing to exist to be able to read it.

Portability isn’t just being able to download a file: it’s that what you download is useful somewhere else. That’s why Shara is built on open standards at every layer that connects you to the outside:

• OAuth connectors, not resale. Your integrations (email, calendar, CRM, storage) are yours: you authorize Shara via OAuth and revoke that access at the provider itself whenever you want. There’s nothing to “get back” because it never stopped being yours.
• Tools via MCP. The tool bridge uses Model Context Protocol, an open standard. What you expose to the agents doesn’t stay locked in a Shara-proprietary format.
• Identity in Markdown. Your IDENTITY.md is a human-readable text file; you can version it, edit it externally and re-import it.
• Plain REST API. Everything the panel does you can do via the standard REST API, with JSON and normal headers. No mandatory SDK or closed protocol.

Let’s be concrete. The day you decide to leave, this is exactly what walks out the door with you:

• Your whole corporate identity and its change history, ready to reuse in any system.
• The full conversation history with Amadeus and the agents.
• All the drafts and documents the agents produced for you.
• The full audit log, which is your defensible proof for a client or an inspection.
• The consumption and billing in CSV for your accounting.
• The configuration of your team, agents and departments, in case you rebuild the flow elsewhere.

And a hygiene promise: when you close the account, after the retention period agreed in the DPA, we delete your data from our systems. We don’t keep a copy “just in case”.

Honesty is part of not tying you down. There are things that, by their own nature, aren’t part of the export, and we’d rather say it clearly before you discover it yourself:

• The AI model weights. On cloud plans, the engine is served by an external provider under its own license; it isn’t ours to give you, just as it isn’t any other platform’s. What is yours is everything that engine produced while working for you. If you need the model inside your own house, Concerto Local exists (below).
• The orchestration itself. Amadeus and the agents’ behavior is a Shara product. You take its results and your configuration, not the code that coordinates them.
• Your connectors’ live tokens. They aren’t exported because they aren’t data: they’re third-party credentials you manage and revoke at the source provider (Google, Microsoft, your CRM).

If your threshold for peace of mind is “nothing depends on someone else’s servers”, the answer is Concerto Local: Shara deployed 100% on your own infrastructure, on-premise, with the local Concerto engine. It’s the strongest way to have no lock-in, because it removes the dependency on our servers at the root.

• Everything at home. Data, model and execution live on your machines. Nothing goes out to the network except what you decide to connect.
• Works without us. If one day AIGiner were to disappear, your Concerto Local deployment keeps working: it doesn’t call our servers to reason.
• Operates offline. Concerto runs locally, so you don’t even need the internet for the agents to work.
• Same product. The same agents, the same corporate identity, the same auditing, the same API. What changes is where it runs, not how it’s used.

Concerto Local is built for those with strict data sovereignty or compliance requirements. For cloud clients, we also keep in escrow the migration policies to another MCP-compatible platform.

• How do I know the model is good? Every agent has an eval suite that runs before any change is promoted; if measured quality drops, it isn’t applied.
• Can I choose the provider? On Max and Concerto Local, yes (NDA + veto over changes).
• Does the export cost money or require permission? No. It’s an included feature and a GDPR right; you launch it yourself from Settings → Data.
• Is the exported data useful outside Shara? Yes. It comes out in open formats (JSON, JSONL, Markdown, CSV) that any tool can open, with no dependence on us.
• What happens to my data if I close the account? It’s deleted after the retention period agreed in the DPA. We don’t keep silent copies.
• And if your company disappears? Concerto Local runs on-premise with Concerto with no dependence on our servers; cloud clients receive in escrow the migration policies to another MCP-compatible platform.
• Why classical-music names? They’re neutral, memorable and reflect the hierarchy: Prelude, Sonata, Symphony, Concerto.