AI Acceptable Use Policy

1What the model actually does here

It is worth being precise, because most of this policy follows from it. In Silo the model does not touch your data at scale and does not write code that runs against your systems. It reads your question and produces a structured plan, which is validated against a schema and then executed by a deterministic engine we wrote.

The model is used to compile a question into that plan, to generate a connector profile from documentation, to propose a repair when a source system changes shape, and to frame a bounded set of results in words. Everything else, including the execution itself, is ordinary software.

That boundary is what makes an answer checkable, and most of the rules below exist to keep it intact.

2Who this applies to

It applies to every person who uses Silo through your organisation’s account, and to anything done with an API credential issued to you. You are responsible for making the people on your account aware of it.

3What you must not do

Against the law, or against people

• Break the law, or help somebody else to. This includes fraud, money laundering, and evading sanctions or export controls.
• Build a profile of an identified person for the purpose of harassing, intimidating, stalking or discriminating against them.
• Take a decision about a person that has a legal or similarly significant effect on them, in employment, credit, insurance, housing, education or benefits, on the output of a compile alone. A person has to decide, on evidence they have looked at.
• Infer a person’s health, sexuality, religion, political opinions, trade union membership, racial or ethnic origin, or biometric identity, where that inference is the purpose of the question rather than a fact recorded in your systems for a lawful reason.
• Use Silo for surveillance of individuals beyond what your lawful basis as an employer or service provider permits.

Against the systems

• Connect a system you are not authorised to connect, or use a credential you were not given for this purpose.
• Attempt to make the model produce a plan that exceeds the permissions of the person asking, or to have it disclose a field your roles exclude. The compiler removes such fields before a plan exists; trying to defeat that is a breach of this policy whether or not it succeeds.
• Attempt to bypass the write pipeline: the preview, the approval, the bulk thresholds or the checks a revert makes. Approving your own change where your organisation requires a second approver is a breach of this policy as much as of your own controls.
• Feed the model instructions through data in a connected system in order to change what Silo does for another user. If you find that you can, tell us rather than using it.
• Probe, load test or attempt to extract the model, the prompts or the ontology, or use Silo to build a competing service.

Against the meter

• Share a seat between people, or automate a seat to consume an allowance on behalf of others.
• Generate compiles at a volume with no business purpose, whether to exhaust an allowance, to benchmark us, or to load the service.

4What we ask of you, rather than require

Read the preview before approving a write. It exists because a plan is easier to check than a consequence, and the approval is recorded against your name.

Follow the lineage when a figure surprises you. Every number Silo returns carries a path back to the field and connector version it came from, and a surprising number is usually a correct reading of something unexpected in a source system.

Treat a refusal as information. When a question cannot be answered within bounds, Silo says so and suggests how to narrow it, rather than returning a partial answer that looks complete. Rephrasing to force an answer past that point is how you get a confident wrong one.

5What we do on our side

We constrain the model to output validated structure, never executable code and never direct access to your data at scale. We apply your roles and field policies when the plan is compiled, not after the data comes back.

We do not train on your data, or on the content of your questions. Model calls run under a zero-retention arrangement with our provider. We pin the model version rather than tracking a moving alias, so its behaviour does not change under a running deployment without a deliberate change on our side.

We meter model work and publish what each operation costs in tokens. A compile that we refuse does not consume one, and a rephrase of the same question inside a short window is charged once.

6Generated connectors

Silo can generate a connector from documentation you provide. Generation is probabilistic and documentation is often wrong, so a generated connector is probed against the live system in a sandbox before it is trusted, and writes stay disabled until a sandboxed write, verify and undo cycle passes.

You are responsible for the documentation and credentials you supply to a generation, and for confirming that a generated connector reads what you believe it reads before you rely on it for a decision.

When a source system changes shape, Silo proposes a repair and tests it in a sandbox. When a field changes meaning rather than name, it stops and reports rather than repairing, because that is not a repair. Do not configure around that behaviour.

7Reporting a problem

If you find a way to make Silo exceed a permission, bypass an approval, or disclose something it should not, tell us at hello@silohq.io before you tell anybody else. We will acknowledge within two working days, keep you updated, and will not pursue a claim against somebody who reports a genuine finding in good faith and does not exploit it or disclose it prematurely.

8What happens if this policy is broken

Our response is proportionate to what happened. In most cases it starts with a conversation, because most breaches of a policy like this are a misunderstanding of what the product is for rather than an attempt to misuse it.

• We may contact you and ask you to stop.
• We may rate limit or suspend a particular capability, or a particular seat.
• We may suspend the account where use presents a genuine risk to you, to us or to another customer, and we will tell you why at the time.
• We may end the agreement under clause 8 of the Terms of Service where a serious breach is not fixed.

Where the law requires us to report something, we will, and we will tell you we have unless we are prohibited from doing so.

9Changes to this policy

Capabilities change and this policy changes with them. If a change materially restricts what you may do, we will tell customers at least 30 days before it takes effect. Changes that clarify existing rules, or that respond to a security matter, take effect when published.