Privacy Policy

1. Scope and responsible organization#

This Policy applies to information processed by SRC AI through SRCAI.co. Verified legal-entity, address and contact details will appear only after authorized review and publication. Until then, the Website does not invent them; privacy requests may be initiated through the contact form.

Independent sites and Providers linked from SRCAI.co have their own privacy practices. Product-specific notices may add detail for a future SRC Mentor pilot, SRC Launch engagement or authenticated service.

2. Website visitors and technical requests#

When a browser requests a page, hosting and security infrastructure necessarily processes network information such as IP address, request time, path, user agent, protocol and response status. This data is used to deliver content, route traffic, prevent abuse, investigate faults and protect the service. Infrastructure logs are not used to invent a customer profile.

Authorized hosting and structured-storage Providers may process technical requests to operate the Website. Their applicable locations, logging, security and subprocessor terms are reviewed as part of production governance.

3. Contact enquiries#

The contact form collects name, email, optional company, product interest, category, subject, message, privacy acknowledgement, source page and limited attribution. SRC AI uses the record to respond, route the request, manage follow-up, prevent abuse, understand legitimate interest and maintain an audit trail.

Do not include identity documents, account credentials, payment information, health records or other sensitive data. If SRC AI needs protected information for a later service, it should provide a purpose-built secure channel and an appropriate notice first.

4. SRC Launch enquiries#

The public SRC Launch form collects name, email, country of residence, jurisdiction of interest, business category, business purpose, phone/video consultation preference, optional preferred contact method, optional context, consent and attribution. It is used to assess the request, communicate, check whether a supported path may exist, reduce fraud and maintain the enquiry record.

The public form does not request passports, government identifiers, beneficial-ownership evidence, payment data or formation documents. If an engagement proceeds, SRC AI or an approved Provider may later request additional identity, ownership, sanctions, tax or filing information under a separate secure workflow and notice.

5. Newsletter and double opt-in#

A newsletter request records the email address, affirmative consent, status, source page, UTM attribution, subscription time and protected confirmation and unsubscribe references. The address remains pending until the recipient follows the confirmation link. Confirmation time and unsubscribe time are recorded so SRC AI can respect the choice and evidence the subscription lifecycle.

Newsletter confirmation delivery remains NOT CONNECTED until an approved delivery service is ready. Delivery status must not be represented as successful when no provider accepted the message. A subscriber can withdraw consent using the unsubscribe link.

6. Attribution, referrers and campaign data#

Forms may record the referring page and UTM source, medium and campaign values supplied in a URL. This helps distinguish direct, campaign and partner interest and evaluate public communications. These strings can be user-controlled and are treated as untrusted input rather than verified identity.

SRC AI should avoid combining attribution with unrelated datasets or retaining it longer than the enquiry or analytics purpose requires.

7. Cookies, storage and consent preferences#

Essential cookies or equivalent storage may support protected services, security and abuse prevention. A device-local preference records whether the visitor allowed optional first-party measurement so the choice can be respected. Optional analytics events should be recorded only after the visitor permits measurement where consent is required.

Advertising and third-party marketing trackers are not currently connected. Future marketing integration requires a reviewed cookie inventory, purpose, provider, duration and consent behavior before activation. The Cookie Policy gives more detail.

8. First-party analytics#

When permitted, first-party analytics may record a bounded event name, path, referrer, product label, pseudonymous visit identifier and time. Current measurement is intended to understand page use and conversions such as completed enquiries, not to infer sensitive traits or create invented marketing audiences.

External analytics is NOT CONNECTED unless the public Website truthfully states otherwise. Production retention, IP treatment and consent requirements must be confirmed before any external provider is enabled.

9. Public AI Assistant questions#

The Assistant processes the question long enough to apply safety and abuse protections, retrieve approved public material and return an answer. Visitors are told not to include personal, confidential or sensitive information. The Assistant is not a secure support channel.

The application minimizes retained telemetry: it stores an event outcome, broad topic, source paths, escalation flag, time and a one-way fingerprint used for aggregate abuse or repetition analysis. It does not intentionally store the full question, system instructions, generated answer, secret values or model prompt in the analytics table. If an external model Provider is later connected, its processing and retention terms must be reviewed and disclosed before production use.

10. Knowledge gaps and assistant improvement#

When a legitimate public question cannot be answered, the system may record a broad gap topic such as company-contact, pricing or availability and count similar events. This helps the editorial team decide whether approved public content should be improved without exposing unnecessary conversation text.

A one-way query fingerprint is not used to identify a visitor. Source material is rebuilt from current published records at request time; legal drafts, CMS drafts and unpublished Company Profile values are excluded.

11. Company Profile and social links#

The governed Company Profile can hold brand and organization details used across the Website. Blank values remain private. Every official identifier is private by default and appears publicly only after authorized publication specifically enables that identifier for an appropriate surface.

The Social Registry stores platform, HTTPS profile URL, handle, label, verification note and status, enabled state and timestamps. Only enabled records are exposed publicly. SRC AI does not receive a social-network account merely because a blank registry entry exists.

12. Administrative security and audit data#

SRC AI applies layered security, secure data handling and protected administrative controls across its systems. Sensitive internal capabilities remain isolated from public-facing services, and access-related data is limited to what is reasonably needed to operate and protect those capabilities.

Security and accountability records may identify the responsible actor, action, affected record, outcome and time while excluding confidential access credentials and unnecessary sensitive content. Detailed control design is intentionally not published.

13. Public-form abuse controls#

Public forms and the Assistant apply proportionate validation and abuse protections. These safeguards protect service integrity and reduce fraud; they are not used to make consequential eligibility decisions about a person.

Security evidence may be retained longer than ordinary analytics when reasonably necessary to investigate an incident, defend a claim or prevent repeated abuse.

14. Purposes and legal bases#

Depending on the user’s location and the interaction, SRC AI may process information to take steps requested before a service, perform an accepted service, comply with law, pursue legitimate interests in operating and securing the Website, or act on consent for optional analytics and newsletter marketing. The appropriate basis must be assessed for the relevant jurisdiction; this Policy does not declare one basis universally applicable.

Consent may be withdrawn prospectively. Withdrawal does not make earlier processing unlawful and may not require deletion of records that SRC AI must retain for another valid basis.

15. Service providers and disclosures#

SRC AI may disclose necessary information to authorized hosting, database, email, security, analytics, payment, document, formation or professional Providers performing defined services. Each production Provider must be subject to appropriate access limits, terms and due diligence. Currently disconnected Providers do not receive data merely because they are listed as future integrations.

Information may also be disclosed when reasonably necessary to comply with lawful process, protect rights or safety, investigate abuse, complete a corporate transaction with appropriate safeguards, or establish and defend legal claims. SRC AI does not sell personal information merely by operating the current Website. Any future practice requiring a statutory sale or sharing notice must be assessed before activation.

16. Resend and future email routing#

When connected, the approved email delivery Provider may process recipient and sender addresses, message content, delivery metadata and provider identifiers to deliver confirmation and enquiry notifications. A verified mailbox may be used for human replies. Production sender verification, retention, suppression and subprocessor terms require authorized review before activation.

Email is not appropriate for confidential access credentials or unprotected identity documents.

17. Search, advertising and external connectors#

Google Search Console, Bing Webmaster, advertising networks, external analytics, payments and secure-document connectors are NOT CONNECTED in the local closure state. If later enabled, SRC AI must document the data categories, purpose, access permissions, lawful basis, retention, opt-out behavior and public notice before production use.

Search-engine discovery is limited to approved public pages. Protected administrative services and draft content are not published to the sitemap or Assistant corpus.

18. Retention#

SRC AI retains records only as long as reasonably needed for the purpose, security, contractual evidence, dispute handling and legal obligations. A production schedule must assign approved periods by category before launch. Pending newsletter records should be removed or revalidated after a reasonable confirmation window; unsubscribe suppression may be retained to respect the choice; enquiries may be kept while active and for a proportionate evidence period.

Administrative access data is time-bounded and can be invalidated. Audit and security records may require a longer controlled period. Legal revisions remain archived to evidence what terms were public. Backups and Provider logs may delete on a delayed cycle.

19. Security#

SRC AI applies layered security, secure data handling and protected administrative controls across its systems. Sensitive internal capabilities remain isolated from public-facing services.

No online system can guarantee absolute security. Safeguards are reviewed as the service and its Providers evolve. A person who suspects compromise should stop sending sensitive information and use the contact route to request an appropriate reporting method.

20. International processing#

Hosting, email and other Providers may process information in countries different from the user’s. Before production activation, SRC AI must identify material locations and use safeguards required for relevant transfers, which may include contractual measures, transfer assessments or reliance on an approved legal mechanism.

This candidate does not claim that every transfer mechanism or adequacy decision applies. Rights can vary by location.

21. Individual choices and rights#

You may unsubscribe from newsletters, change optional analytics consent, correct an active enquiry and ask about access, correction, deletion, restriction, objection, portability or withdrawal where applicable law provides those rights. SRC AI may need to verify identity and authority, clarify scope, protect another person’s information and preserve records subject to a lawful exception.

If a request is denied or limited, SRC AI should explain the reason where lawful and identify any available complaint or appeal route. Users may have a right to complain to a competent privacy authority.

22. Children, families and SRC Mentor#

The current public Website, forms, newsletter and Assistant are not designed for children to submit personal information independently. Parents and guardians should not place a child’s personal, educational, health or identity information into public channels. If SRC AI learns that unintended child data was submitted, it will assess deletion, safety, evidence and legal obligations.

Any future SRC Mentor experience for minors requires age-appropriate design, verified guardian authority where required, data minimization, clear roles, restricted profiling, safety review and product-specific notices before activation. See the Children & Family Privacy Notice.

23. Legal process, complaints and contact#

Questions, notices, complaints and requests may be sent through the SRC AI contact form. Use the category that best matches the request and provide enough information for SRC AI to identify the relevant interaction. Do not send account credentials, payment-card data, identity documents or other sensitive records through a public form. SRC AI may ask for proportionate evidence of identity or authority through an appropriate protected channel before acting on a request.

A privacy request should state the interaction, email or reference needed to locate the record and the right being requested. Do not send additional identity evidence until SRC AI provides a suitable method. The verified privacy or legal contact will be published from the Company Profile when approved.

24. Policy updates#

The public page identifies the Effective Date, Last Updated date and version. Material changes will be published prospectively, and additional notice or consent will be used where required. A controlled legal record retains revision history. Production launch requires a final review against the actual legal entity, Providers, locations and retention schedule.

25. Data inventory, purpose limitation and ownership#

SRC AI should maintain an internal inventory linking each production data category to its source, purpose, access group, Provider, location, retention rule and deletion method. Adding a data field or integration does not itself authorize collection. Before a new category is enabled, authorized governance should confirm that it is necessary, represented accurately in public notices and protected in proportion to its sensitivity.

Personal information remains information about the relevant individual; this Policy does not transfer ownership of it to SRC AI. SRC AI controls its software, schemas, aggregated operational measures and independently created analysis, but must not use that distinction to reconstruct an identifiable profile from information promised to be minimized or deleted.

26. Access controls and privileged operations#

SRC AI uses layered protection to isolate administrative capabilities from public-facing services. Detailed authentication and authorization design is intentionally kept out of public documentation.

Production access is limited to authorized people with a genuine operational need. Shared credentials should not be used. Access removal and exceptional access are governed internally. Providers receive only the data and permissions necessary for their role and must not use SRC AI information for an unrelated purpose unless a lawful, disclosed arrangement permits it.

27. Security safeguards and residual risk#

SRC AI applies layered security, secure data handling and protected administrative controls. Sensitive internal capabilities remain isolated from public-facing services, and safeguards are reviewed as technology and Providers change.

No system can eliminate every risk. Phishing, device compromise, Provider failure, software vulnerability, human error and sophisticated attacks can affect even carefully designed services. Users should avoid unnecessary sensitive submissions and promptly report suspicious communications. A statement that safeguards exist is not a certification or guarantee that an incident cannot occur.

28. Incident assessment and notification#

SRC AI maintains governed processes for assessing and responding to suspected personal-information incidents while limiting unnecessary disclosure of sensitive defensive information.

Where applicable law or a contractual duty requires notification, SRC AI will provide appropriate notice to affected people, customers, Providers or authorities within the required period and with the required content. This Policy does not expand or reduce a mandatory notification duty.

29. Requests to access, correct, delete or restrict#

A person may use the contact form to ask what information SRC AI holds, correct inaccurate information, request deletion, object or restrict processing, withdraw consent or request a portable copy where the relevant law provides that right. The request should identify the interaction and right without sending credentials or identity documents through the public form.

SRC AI may verify identity or authority using proportionate means and may ask for clarification. It may redact another person’s information and may retain data needed for security, legal claims, tax, fraud prevention, Provider reconciliation or other lawful obligations. If a request is denied or limited, SRC AI should explain the applicable reason and complaint route where required.

30. Requests made by representatives and guardians#

An authorized agent, parent, guardian or organizational representative may submit a request where law permits, but SRC AI must verify both the requester and the claimed authority. Authority can be limited by territory, age, court order, organizational role or the subject person’s own rights. SRC AI should not disclose information merely because a requester knows an email address or describes a relationship.

For a child or family matter, SRC AI should prioritize safety and minimization and avoid exposing one family member’s confidential information to another without a valid basis. A future SRC Mentor workflow must define guardian controls, age-appropriate notices, escalation and changing authority before accounts are offered.

31. De-identification, aggregation and measurement#

SRC AI may aggregate counts such as page events, enquiry categories, Assistant outcome classes, refusal counts and broad knowledge-gap topics to operate and improve public services. Aggregation should remove direct identifiers and avoid groups so small that a person can reasonably be inferred. A one-way fingerprint used for abuse or repetition analysis should not be treated as anonymous if it can still be linked in context.

De-identified information should not be deliberately re-identified except to test safeguards, investigate a security problem or comply with law under controlled access. Reports must not present synthetic, test or empty-state numbers as real customers, revenue, threats or performance. Protected operational reporting should label unavailable and not-connected metrics truthfully.

32. Provider onboarding, change and termination#

Before connecting a production Provider, SRC AI evaluates the service purpose, information involved, locations, subprocessors, safeguards, retention, deletion and relevant contract terms. The public notice and consent behavior should be updated before data begins flowing when the change is material.

When a Provider is removed, SRC AI stops the relevant routing and addresses necessary export, deletion, residual backups and legal records. A disconnected label must reflect the actual state. Architecture prepared for a future Provider does not mean that Provider currently receives information.

33. Automated output and decision support#

The public Assistant retrieves and presents approved information and classifies outcomes such as grounded answer, safe refusal or knowledge gap. It is not designed to make a binding eligibility, employment, credit, legal, education, immigration or government decision about a person. Safety refusals protect the service but should not be represented as a substantive judgment about the user.

If a future service introduces automated profiling or a decision with legal or similarly significant effect, SRC AI must assess necessity, accuracy, bias, explanation, human review, objection rights and applicable law before launch and provide a specific notice. This Policy does not claim that such a future assessment has already occurred.

34. Privacy governance, review and accountability#

Authorized governance should review the data inventory, retention, access, Provider status, rights requests, incidents, legal changes and policy accuracy on a documented schedule and after material releases. Legal publication requires an approved revision and explicit authorized confirmation so public text cannot change through an unreviewed draft.

Production readiness also requires a verified controller identity, lawful-basis assessment, subprocessor list, transfer analysis, deletion verification, backup rules, incident contacts and staff procedures. This candidate describes controls and remaining decisions transparently; it does not substitute documentation of those decisions or independent professional review.

35. Retention schedule and review triggers#

Production retention should be set by category rather than one indefinite period. Contact and Launch enquiries, pending newsletter records, confirmed subscriptions, consent evidence, optional analytics, Assistant events, protected operational records, legal revisions, Provider delivery records and financial or accepted-service records have different operational and legal needs. Each schedule should identify the start event, ordinary period, deletion or anonymization method and approved exception.

Review is triggered by purpose completion, unsubscribe, account closure, Provider removal, rights request, incident, dispute, legal hold and policy change. A record should not be kept merely because storage is inexpensive. Conversely, deleting evidence needed for security, consumer rights, tax, filing or a live claim can harm users and legal duties.

36. Backups, caches and deletion completion#

Deletion from an active application record does not always remove a copy immediately from a protected backup, email delivery record, browser cache or independent authority system. Production governance should define backup retention and restoration safeguards. Restored records must not silently reactivate a prior newsletter choice or invalidated access.

SRC AI should record completion of a verified deletion request without retaining the deleted content itself. It cannot delete information controlled by a registry, social platform, email recipient or other independent Provider, but may direct the requester and make a supported request where its role permits.

37. Children, family and safeguarding information#

The current public Website is not a child account service and tells visitors not to submit child or educational records. General technical logs can still concern a device used by a child, so collection remains minimized. A parent or guardian may request general SRC Mentor information without naming or profiling a child.

Before a child or family feature launches, SRC AI must establish supported ages, guardian authority, age-appropriate notice, lawful consent or other basis, safeguarding access, Provider limits, retention, deletion and incident handling. The Children & Family Privacy Notice describes this release gate without claiming a formal regime has already been assessed.

38. Online choices, browser signals and marketing#

The Cookie Choices control governs optional Website measurement on the browser where it is set. Newsletter consent is separate and follows double opt-in. An advertising or cross-site marketing Provider is not connected in the current state. If one is proposed, SRC AI must assess applicable opt-in, opt-out, sale or sharing rules and recognized browser signals before activation.

A browser signal may not identify which email or enquiry record a visitor means, and a newsletter unsubscribe may not clear browser storage. SRC AI should provide specific controls for each processing context rather than treating one action as universal.

39. International transfers and remote access#

Hosting, email, security or other Providers and authorized personnel may process information from different countries. Before production, SRC AI should map relevant locations, determine its role and use an applicable transfer mechanism, contractual safeguard or recognized adequacy basis where required. A Provider’s global brand is not itself a transfer assessment.

Remote access should use least privilege, secure authentication and a documented business need. The protections promised in this Policy continue when information is processed from another location, subject to lawful government access and the limits of applicable mechanisms.

40. Privacy complaints and supervisory routes#

A privacy complaint can be submitted through the contact route and should identify the interaction, concern and requested resolution. SRC AI should acknowledge, verify where necessary, investigate relevant systems and Providers and give a reasoned response. It should not require excessive identity evidence for a low-risk question.

Depending on location, a person may have a right to complain to a privacy, consumer or other competent authority. The final controller identity and applicable authority must be configured accurately before production; this candidate does not invent a regulator. Using the internal route does not remove a non-waivable external right.

41. Legal process and organizational change#

SRC AI may receive a subpoena, order, regulatory request or other legal demand. It should validate authority, scope and jurisdiction, seek limitation where appropriate, document the response and notify affected people when lawful. Informal requests should not receive private data merely because they appear official.

If SRC AI undergoes financing, reorganization, merger, acquisition or asset transfer, limited information may be reviewed under confidentiality and transferred with appropriate safeguards and notice where required. A potential transaction does not permit unrelated marketing use.

42. Policy versions and notice of material change#

Each published revision shows its version, Effective Date and Last Updated date. Drafts, authorized review and approved-but-unpublished candidates remain private and do not change public processing descriptions. Publication requires explicit authorized confirmation, and the audit records the action without storing confidential access values.

Material changes such as a new data category, model Provider, advertising use, child feature or significant transfer may require prominent notice or renewed consent before taking effect. Editorial clarification can be made prospectively without manufacturing consent for an unrelated purpose.

43. Email content and delivery metadata#

When email is connected, SRC AI and the delivery Provider process sender and recipient addresses, subject and message content, template and campaign identifiers, delivery attempts, timestamps, bounces, complaints, opens or link events only if those measurements are enabled and lawfully configured. Confirmation and unsubscribe records are protected so raw authorization values need not be recoverable from ordinary records.

Human replies can contain information supplied by the correspondent. SRC AI should keep email within the approved mailbox, restrict access and avoid forwarding sensitive material into unrelated systems. Production decisions must address tracking settings, suppression records and mailbox retention before live sending.

44. Contact matching and duplicate records#

The same person may submit contact, Launch and newsletter records using the same email address. The current system does not treat that fact as permission to merge every purpose into one profile. Records may be matched where needed to respond, prevent duplicates, honor unsubscribe or investigate abuse, with access and retention limited to those purposes.

A newsletter opt-out does not delete a legitimate active-service message, and a contact enquiry does not create newsletter consent. If duplicate records are consolidated, the system should preserve the source, status and applicable choice rather than converting a pending or unsubscribed address into confirmed.

45. Accuracy and correction at the source#

SRC AI relies on users, Providers and public authorities for some information. It should correct information it controls when shown to be inaccurate and should identify when correction must instead be requested from an independent registry, social platform, email Provider or other source. A link to an external record is not ownership of that record.

Correcting a Company Profile field requires authorized review and publication. Correcting a customer submission may require an audit trail rather than overwriting the original instruction, especially after a filing, payment or dispute.

46. Contact channels and sensitive evidence#

An initial privacy request may be made through the contact form without attaching identity evidence. If verification is needed, SRC AI should provide a proportionate protected route and explain what is required and why. Confidential access or payment credentials are never appropriate verification evidence.

SRC AI should keep privacy correspondence separate from marketing use and limit access to people handling the request, security or legal review. The verified privacy or legal email may be published through Company Profile when approved.