AI / Training Use

AI / Training Use Policy

This AI / Training Use Policy explains how Etalyon Sàrl-S, operating Squillify ("Squillify", "we", "us", or "our"), uses, and does not use, customer data in relation to artificial intelligence, machine learning, model training, model improvement, evaluation, and external AI-backed capabilities.

This policy is a draft and is not effective until published as active by Squillify. It is intended for product, security, privacy, and legal review before launch.

1. Purpose

Squillify is designed as a deterministic microskill execution platform. Its core purpose is to let applications, developers, AI agents, automation systems, and other software clients invoke explicit capabilities through controlled APIs.

This policy explains:

• whether customer microskill payloads are used for AI model training;
• whether customer payloads are used to improve models;
• how operational metadata may be used;
• how external AI-backed providers are handled;
• how future AI-backed Squillify capabilities must be labelled;
• how this policy relates to privacy, data protection, telemetry, and sub-processors.

2. Core position

Squillify does not use customer-submitted raw microskill input or output payloads to train artificial intelligence or machine learning models.

Squillify does not use customer-submitted raw microskill input or output payloads to improve third-party AI models.

Squillify does not sell customer-submitted raw microskill payloads for AI training.

Squillify does not send customer-submitted raw microskill payloads to hidden external AI providers unless the relevant capability is explicitly labelled as using an external service.

3. What this policy covers

This policy covers:

• microskill input payloads;
• microskill output payloads;
• uploaded files used for microskill execution;
• generated files used for microskill execution;
• temporary file references;
• API request metadata;
• telemetry metadata;
• support examples provided by customers;
• future AI-backed capabilities, where applicable.

This policy applies to the default Squillify platform behaviour. Individual capabilities may have additional data handling notices where they process data differently.

4. Customer payloads

Customer payloads are the inputs, outputs, files, or other submitted content processed by Squillify to perform a requested microskill execution.

Default rules:

• payloads are processed to perform the requested execution;
• raw submitted payloads are not permanently stored as part of normal execution;
• payloads are not used to train Squillify models;
• payloads are not used to train third-party models;
• payloads are not used to build customer-specific training datasets;
• payloads are not used to build shared training datasets;
• payloads are not used for model fine-tuning;
• payloads are not used for embedding datasets intended for model training;
• payloads are not used for reinforcement learning, supervised training, or evaluation sets unless expressly agreed in writing with the customer.

5. Operational metadata

Squillify may process operational metadata for legitimate platform purposes.

Operational metadata may include:

• request timestamp;
• tenant identifier;
• API key identifier or derived identifier;
• skill key and version;
• execution status;
• latency;
• error codes;
• quota events;
• rate-limit events;
• billing counters;
• usage counters;
• file metadata;
• payload size;
• content type;
• retention status;
• deletion status;
• performance metrics;
• security and abuse signals.

Operational metadata may be used for:

• billing;
• quota enforcement;
• rate limiting;
• security monitoring;
• abuse prevention;
• debugging;
• reliability monitoring;
• capacity planning;
• product analytics;
• service improvement;
• aggregate reporting;
• compliance and audit support.

Operational metadata is not used as model training data unless Squillify expressly updates this policy and the applicable privacy/legal terms, and only where permitted by applicable law.

6. Aggregated and anonymised information

Squillify may use aggregated, statistical, or anonymised information derived from use of the platform to understand and improve the service.

Such information may include:

• total number of executions;
• skill popularity;
• aggregate latency;
• aggregate error rates;
• aggregate quota consumption;
• aggregate file handling volume;
• platform reliability metrics;
• category-level usage trends.

Squillify will not intentionally use aggregated or anonymised information to identify a customer, user, data subject, or raw payload content.

Where information is personal data under applicable law, Squillify will process it in accordance with the Privacy Policy, the Data Processing Agreement where applicable, and Applicable Data Protection Law.

7. Support examples and customer-provided materials

Customers may voluntarily provide examples, payloads, logs, screenshots, files, or other materials to support.

Such materials are not used for AI model training unless the customer expressly agrees in writing under specific terms.

Customers must remove or mask sensitive, confidential, regulated, personal, or unnecessary data before providing materials to support.

Support materials may be used to:

• investigate the support request;
• reproduce a defect;
• improve documentation;
• improve reliability;
• improve tests or validation logic;
• improve security and abuse prevention.

Where support materials are used for internal tests, Squillify should use sanitized, minimised, or synthetic examples where practical.

8. Synthetic and test data

Squillify may create and use synthetic, generated, public, non-customer, or internally authored test data to build, test, evaluate, benchmark, or improve microskills and platform behaviour.

Such data is not customer payload data unless a customer provided it and expressly agreed to its use for that purpose.

9. External service providers

Some capabilities may rely on external service providers.

Where a skill or feature uses an external provider, Squillify will identify the provider and relevant data handling implications through one or more of:

• the skill page;
• data handling labels;
• the External Service Use Policy;
• the Sub-processors page;
• the Privacy Policy;
• the Data Processing Agreement;
• specific product notices.

Where an external provider processes customer data, that provider's own terms, privacy policy, data processing terms, and AI/training practices may apply.

Squillify's default policy is no hidden external service use for submitted payloads. External service use must be explicit.

10. External AI-backed services

If a Squillify capability uses an external AI model, AI API, machine learning service, or AI-backed provider, the capability must be explicitly labelled before production use.

The label should identify, where applicable:

• the provider;
• the type of service;
• what data is sent;
• whether input data is retained by the provider;
• whether output data is retained by the provider;
• whether the provider uses submitted data for training or model improvement;
• processing region where known;
• transfer mechanism where applicable;
• whether the feature can be disabled or avoided;
• link to provider terms or data processing terms.

Squillify should not market an AI-backed external capability as self-contained, local, deterministic, or no-external-service.

11. Future Squillify AI-backed capabilities

If Squillify later offers AI-backed capabilities, such capabilities must be clearly labelled.

Before launch of such capabilities, Squillify should define:

• whether the capability is deterministic or probabilistic;
• whether a model is used;
• whether the model is Squillify-hosted or third-party-hosted;
• whether customer data is sent to an external provider;
• whether customer data is retained;
• whether customer data is used for training;
• whether customer data is used for evaluation or model improvement;
• whether opt-out, tenant disablement, or skill-level restriction is available;
• any relevant AI Act, GDPR, DPA, security, or sub-processor implications.

No future AI-backed capability should silently change the default no-training position for existing microskills.

12. Personal data and GDPR

Customer payloads may contain personal data if the customer submits personal data.

Squillify does not determine whether submitted payloads contain personal data, special categories of personal data, confidential data, regulated data, or third-party data.

Customers are responsible for determining whether their users, agents, applications, API keys, and integrations may submit such data to Squillify.

Where Squillify processes personal data on behalf of a customer, Squillify acts as processor under the Data Processing Agreement unless otherwise stated.

Where Squillify processes personal data for its own platform purposes, Squillify acts as controller as described in the Privacy Policy.

13. Special categories and high-risk data

Customers must not submit special categories of personal data, criminal offence data, health data, children's data, payment card data, government identifiers, authentication secrets, regulated financial data, or other high-risk data unless:

• processing is lawful;
• the customer has authority to submit the data;
• the selected capability is appropriate for that data;
• required contractual, technical, and organisational safeguards are in place.

Squillify does not provide a general-purpose sensitive data detection or classification service and does not guarantee that sensitive or regulated data will be detected or blocked.

14. EU AI Act positioning

Squillify's core microskill platform is intended to provide deterministic software capabilities, not general-purpose AI model training.

If Squillify later provides AI systems, general-purpose AI models, high-risk AI functionality, or AI-backed capabilities within the meaning of applicable AI regulation, Squillify will assess and document the relevant obligations before launch.

Customers using Squillify together with their own AI systems, AI agents, models, or automated decision-making systems remain responsible for determining their own role and obligations under applicable AI, data protection, sector-specific, and consumer protection laws.

15. Automated decision-making

Squillify does not use customer payloads for automated decision-making that produces legal effects or similarly significant effects on individuals.

Customers are responsible for any automated decision-making they perform using Squillify outputs in their own systems.

16. Model evaluation, benchmarking, and quality testing

Squillify may test the platform and microskills for reliability, security, performance, and quality.

Such testing should use:

• synthetic data;
• public data where lawful and appropriate;
• internally authored data;
• customer-provided examples only where the customer has voluntarily provided them for support or testing and where their use is lawful and appropriate;
• anonymised or aggregated information where appropriate.

Customer payloads processed during normal execution are not added to model evaluation datasets unless expressly agreed in writing.

17. Logs and debugging

Squillify may process logs and metadata for debugging, security, billing, abuse prevention, and reliability.

Logging practices are designed to avoid permanent raw payload capture as part of normal execution.

If temporary diagnostic logging is ever required for a specific customer investigation, it must be:

• limited;
• documented;
• authorised where required;
• time-bound;
• access-controlled;
• deleted when no longer needed;
• consistent with the Privacy Policy, Data Processing Agreement, and Data Retention Policy.

18. Customer controls

Customers should use available controls to manage data exposure, including:

• tenant membership controls;
• API key scoping;
• skill access restrictions;
• rate limits;
• quotas;
• application-side data filtering;
• agent guardrails;
• secret management;
• logging controls;
• input minimisation;
• internal approval processes for sensitive workflows.

Squillify may provide labels, policies, documentation, and technical controls, but customers remain responsible for what their systems submit.

19. Changes to this policy

Squillify may update this policy from time to time.

If changes materially affect how customer payloads are used in relation to AI training, model improvement, external AI providers, or AI-backed capabilities, Squillify will provide reasonable notice through appropriate channels.

Squillify will not silently change the default position that customer-submitted raw microskill payloads are not used to train models.

20. Contact

For questions about this policy, contact:

• Privacy: [email protected]
• Legal: [email protected]
• Security: [email protected]
• Support: [email protected]