Responsible AI

On this page, “we” and “us” mean NETSPHERE360 SOLUTIONS PRIVATE LIMITED, whose brand is NS360 (Netsphere360). The page applies to three things:

• AI systems we design, build, integrate or operate for clients: assistants, retrieval and search, agents and workflow automation, document and vision pipelines, and conventional machine-learning models.
• The AI coding and writing assistants used in our own work, including by contractors and partners on our engagements.
• This website.

AI system

Software in which a machine-learning model, including a large language model (LLM), produces predictions, text, classifications or actions.

Client

The organization we are working for.

End users

The people who use, or are affected by, what we build for a client.

This page describes our standard practice. It is not a certification, and it becomes binding only when a signed agreement includes it. Where a client’s contract, policies or regulator require something stricter, we follow the stricter rule.

Most AI risk is settled before any code is written: what the system is for, what data it may use and who it affects. Those are the client’s decisions, because the client runs the service and answers to its users and regulators. Our job is to make sure those decisions are well informed and that the system honors them.

Before recommending AI, we ask whether a rule, a search index, a better form or a simpler workflow would solve the problem more cheaply and more predictably. If it would, we say so, even when the client came to us asking for AI.

• Name the task precisely. “Summarize support tickets for triage” can be measured. “Add AI to support” cannot.
• Count the cost of being wrong. A poor autocomplete suggestion is cheap. A wrong refund, diagnosis or credit decision is not. Higher stakes mean stronger evaluation and more human review, or not using AI at all.
• Check the data. We confirm that the data the system needs exists, is good enough, and may lawfully be used for this purpose.
• Set budgets up front. Every AI feature gets an agreed quality bar, a cost per task and a response-time limit before we build it.
• Prefer the smallest thing that works. A smaller model, a narrower task, or deterministic steps around the model are often more reliable than a bigger model.

A good demo is not evidence. Every AI system we build is measured against an evaluation set built for its task, and the client sees the results before deciding whether to launch.

How we evaluate

• Real cases. We build evaluation sets from real examples of the task, with the client’s permission and de-identified where possible. They include the hard, rare and ambiguous cases, not just the easy ones.
• Adversarial cases. We add inputs designed to break the system: prompt-injection attempts, out-of-scope questions, malformed documents and requests it should refuse.
• Measured quality. We choose metrics that fit the task, such as accuracy, whether answers are supported by their sources, and whether the system declines when it should. We report them with the number of cases behind them.
• Cost and speed. We measure cost per task and typical and worst-case response times against the agreed budgets.
• Calibrated graders. When a model grades outputs automatically, we first check its grades against human judgment on a sample, and keep people reviewing what it cannot grade reliably.

Launch and change

• Launch criteria are agreed in writing before the build starts, so the bar does not move to fit the results.
• Regression checks. Any change to a model, model version, prompt, retrieval setup or tool re-runs the evaluation before it reaches production. A change that makes results worse does not ship without the client’s explicit agreement.
• We pin model versions where the provider allows it, so behavior does not change underneath the client without a check.
• Evaluation sets built from a client’s data belong to the client and are handed over with the system.

Language models produce fluent text whether or not it is true. Where an answer must be verifiable, such as policies, contracts, technical documentation or a record of what was said in a meeting, we ground the system in approved sources rather than in the model’s memory.

• Retrieve, then answer. The system answers from passages retrieved for the question, drawn only from sources the client has approved.
• Cite precisely. Answers point to the passage they rely on, such as a document and page or a recording and timestamp, so a person can check them in seconds.
• Decline when the evidence is thin. If the sources do not support an answer, the system says so instead of guessing. We measure how often it makes unsupported claims and treat that as a core quality metric.
• Keep sources current. We design how the source index is updated, and how removed or superseded documents stop being used.

We sort each use of AI by what happens when it is wrong. Drafts and suggestions that a person will read anyway need little ceremony. Decisions that affect someone’s money, work, health, access to a service or legal position need a person in charge.

• Human in the loop. For consequential decisions, the system recommends and a designated reviewer decides. The reviewer sees the evidence, the sources and any uncertainty, not just a verdict.
• Easy override. A reviewer can reject or correct an output in one step. Overrides are recorded so they can improve the system.
• Clear escalation. We build a route to a person, staffed by the client, and the system hands over when it is out of its depth or when the user asks.
• Confirmation before action. Agents that can change things, such as sending messages, moving money or editing and deleting records, ask for confirmation before high-impact actions, or are limited by rules that make those actions impossible.
• Guarding against rubber-stamping. We design review screens so that checking is quick and meaningful, and we recommend sampling approved decisions to spot over-reliance on the system.

Where the EU GDPR applies, people have the right not to be subject to a decision based solely on automated processing that produces legal or similarly significant effects, except in limited cases and with safeguards (Article 22). We design such decisions to include meaningful human review.

• Used only for the engagement. Data a client shares with us is used to build and run that client’s system. We do not reuse it for other clients or for our own products.
• No training without permission. We never use client data to train or fine-tune a third-party model, and never choose settings that let a provider do so, without the client’s explicit written permission. Fine-tuning a model for the client, at the client’s written request, is part of the engagement and is documented.
• Providers that do not train on inputs. We prefer providers, plans and settings under which inputs and outputs are not used for training and are kept for as short a time as possible. We record the provider, processing region and retention settings for each system, and the client approves them.
• Minimize and redact. A model receives only the fields the task needs. Where we can, we remove or mask names, contact details and other identifiers before data reaches a model, and we keep personal data out of logs and evaluation sets unless it is genuinely needed; audit logs, described under Security below, are the main exception.
• Deletion reaches the copies. We design systems so that deleting personal data also removes it from search indexes, embeddings, caches and logs, not only from the main database. Backups age out on a documented schedule. If personal data was used to fine-tune a model, deleting it can mean retraining the model, and we tell the client that before any fine-tuning starts.
• At the end of an engagement, we return or delete the client data we hold, including evaluation sets, indexes, embeddings and any model weights derived from it, within 30 days unless the contract says otherwise, and confirm it in writing.

Roles and the law

Under India’s Digital Personal Data Protection Act, 2023 (DPDP Act), the client is usually the Data Fiduciary and we act as its Data Processor, under a valid contract and only on its instructions.

We build systems that support the client’s obligations under the Act: clear notices, data flows limited to their stated purpose, and working access, correction and erasure. The Act also requires a Data Fiduciary to ensure that personal data is complete, accurate and consistent where it is likely to be used to make a decision that affects the person it relates to (section 8(3)). That is one more reason we evaluate AI systems that feed such decisions.

Where the EU GDPR applies, for example because the client is established in the EU or offers services to people there, the equivalent roles are controller and processor, and transfers of that data to us in India use the Standard Contractual Clauses. Our Privacy Policy explains how we handle personal data on our own account, and Compliance covers the legal framework in more detail.

AI systems inherit every ordinary security risk and add new ones. We use the OWASP Top 10 for LLM Applications as a checklist in design and review, alongside the practices on our Security page.

• Prompt-injection defenses. Text from users, documents, web pages, emails and tool results is treated as data, never as instructions. We separate trusted instructions from untrusted content, filter inputs and outputs, and test with injection attempts before launch, while assuming that some attacks will still get through.
• Least-privilege tools for agents. Each agent gets only the tools and permissions its task needs, with narrowly scoped credentials and read-only access by default. What an agent is allowed to do is enforced in code and configuration, not requested in its prompt.
• Permission-aware retrieval. We build retrieval so that each user gets answers only from documents that user is allowed to see, and we test that boundary before launch.
• Output validation. Model output is checked before anything acts on it. Structured output is validated against a schema, text is escaped before it is displayed, and generated code or queries never run without validation and a sandbox.
• No secrets in prompts. API keys and credentials never go into prompts or model context. We assume system prompts can leak and write them accordingly.
• Usage limits. Rate limits, spending caps and input-size limits stop runaway costs and attacks that rely on expensive requests.
• Audit logs. We log the inputs, retrieved sources, tool calls, outputs and reviewer decisions needed to reconstruct what the system did. These logs can contain personal data, so access, redaction and retention are agreed with the client, subject to any legal minimum, such as the 180-day log retention in the CERT-In Directions where they apply.
• Supply chain. We check the source and license of open-weight models and libraries, and review dependencies before adding them.

For end users

• Where it is relevant, the interfaces we build tell people when they are interacting with AI or reading AI-generated content, for example in chat assistants, AI-drafted messages and generated summaries. The client chooses the wording; we build the disclosure in by default.
• Where a system generates images, audio or video, we label the output as AI-generated and, where the tools support it, add machine-readable provenance marks.
• We do not build systems designed to make people believe they are talking to a human.
• End users are shown how to reach a person and how to report a wrong or harmful answer.

For clients

Every AI system we hand over comes with a plain-language record that covers:

Models and providers

Which models and versions we used, from which providers, and why we chose them over the alternatives.

Data flows

What data goes where, where it is processed, and how long each party keeps it.

Evaluation results

How the system performed against the launch criteria, and the cases it still gets wrong.

Limitations and intended use

What the system is for, what it is not suitable for, and the failure modes we know about.

Operations

The monitoring plan, how to switch the AI off, and what to do when something goes wrong.

An AI system can perform well on average and still fail particular groups of people. We look for those failures deliberately.

• Know who is affected. For each system we identify the people it affects, including people who never use it directly.
• Test the differences that matter. We test across the languages, scripts, accents, names and writing styles the system will meet. In India that often means several languages and mixed-language text. Where relevant, we also test with assistive technology and on slow connections.
• Compare results by group where this is lawful and the data allows, and treat a large gap as a defect to fix, a scope to narrow or a limitation to disclose.
• Write down what remains. Residual risks go into the handover record, where the client can see and act on them.

Uses we decline

We will not build, or knowingly support, AI systems for:

• Covert surveillance or tracking of individuals.
• Tracking or behavioral monitoring of children, or advertising targeted at them.
• Deceptive impersonation, such as imitating a real person’s voice, face or writing without their consent, or bots that pass themselves off as human.
• Decisions with legal or similarly significant effects on people that are made without human review.
• Inferring sensitive characteristics, such as caste, religion, sexual orientation or political opinion, in order to profile or sort people.
• Social scoring, or inferring the emotions of employees or students.
• Manipulating people through deception, or exploiting their vulnerabilities to push them into choices against their interests.
• Creating intimate images of real people without their consent, or any sexual content involving minors.

Where a request is borderline, we discuss it openly with the client and record our reasoning. If a system we are building or maintaining is redirected toward one of these uses, we raise it with the client and may stop work.

AI systems change behavior even when nobody changes the code: users ask new things, source data shifts and providers update their models. We design every system to be watched.

• Signals. Dashboards track quality signals, such as user feedback, reviewer overrides, unsupported answers and refusals, alongside cost, latency and errors, with alerts when they cross agreed limits.
• Drift. The system is re-evaluated on fresh samples of real traffic at an interval agreed with the client, and whenever its inputs, sources or model change noticeably.
• Feedback loops. Reported failures are triaged, fixed and added to the evaluation set, so the same mistake is caught before the next release. We do not retrain a system on its own outputs, or on decisions it influenced, without first checking a sample against human judgment, because that can quietly reinforce errors.
• An off switch. Each AI feature can be turned off, or switched to a simpler fallback, without a new deployment.

Who monitors a system after launch depends on the engagement; see the table under Who decides what, above.

AI incidents

An AI incident is harm, or a near miss, caused by an AI system: a harmful or badly wrong output reaching users, personal data exposed through a model, a successful prompt injection, or an agent taking an action it should not. When we operate a system and find one, we contain it first, tell the client without undue delay and in any case within 24 hours of becoming aware of it, find the root cause and add a test that would have caught it. If we find one in a system we built but do not operate, we tell the client in the same way.

Where an AI incident is also a cyber security incident, the process on our Security page applies. The CERT-In Directions of 28 April 2022 require specified incidents to be reported to CERT-In within 6 hours of noticing them or being told about them. We report those in our own systems where the Directions require it, and we give clients the facts and timeline they need to report incidents in theirs.

Anyone who works on NS360 projects, including contractors, may use AI coding and writing assistants. The assistants help with drafting, exploring unfamiliar code and writing tests. They are also confidently wrong often enough that we treat their output like a first draft from someone we have never worked with.

• On client work, only with the client’s agreement. At the start of each engagement we ask which tools, if any, may be used with the client’s code and data, and we follow the client’s policies. If the answer is no, we do not use them.
• Approved tools and accounts. We use AI tools for work only through company-managed accounts, on plans and settings under which the provider does not train on our inputs.
• No secrets or personal data. We never paste credentials, keys, tokens or personal data into AI tools, or any client confidential material the client has not approved for that use.
• A person reviews and owns every output. Code, tests, documents and designs made with AI help go through the same review, tests and security checks as everything else, and the person who submits the work answers for it.
• Check what the tool invents. We verify that suggested packages, APIs, commands and references actually exist and do what they claim before we use them.
• Licenses checked. We treat AI-suggested code like any third-party code and check that it does not reproduce licensed code we could not ship.
• The same rules for everyone. Contractors and partners working on a client engagement with us follow these rules too.

Work made with AI assistance is delivered under the same signed agreement as the rest of our work, including its terms on ownership. Because the law on who owns purely machine-generated material is unsettled in some countries, a person directs, edits and reviews everything we deliver. Our standard position on intellectual property is summarized under Contracts, and our Approach page describes how we deliver.

• When you use our contact form, your inquiry passes automated anti-spam checks and is saved in our inquiries database. The website does not pass it through an AI model, and no AI features are connected to that database. Once it reaches us, we do not put your personal details into AI tools, and AI assistant features are switched off for the mailbox we reply from. Our Privacy Policy has the details.
• Our public pages are open to AI crawlers, including those that collect pages to train AI models as well as AI search and assistant tools, so that AI assistants can find and describe us. This covers public pages only, never anything you send us. Our robots.txt file lists the crawlers we allow.
• We used AI assistants while building this website, including to draft some of its code and text. We reviewed and edited all of it before publication, and we are accountable for what it says.

No certification. NS360 holds no ISO/IEC 42001 or ISO/IEC 27001 certificate and no SOC 2 report, and no third party has audited the practices on this page. We use the frameworks below as references for how we work.

Law

• India: Digital Personal Data Protection Act, 2023 and Digital Personal Data Protection Rules, 2025. The Rules were notified on 13 November 2025, with most Data Fiduciary obligations taking effect in May 2027.
• India: Information Technology Act, 2000 and the Information Technology (Reasonable Security Practices and Procedures and Sensitive Personal Data or Information) Rules, 2011, which remain in force until superseded.
• India: CERT-In Directions of 28 April 2022, issued under section 70B(6) of the Information Technology Act, 2000, on reporting cyber security incidents.
• India: AI governance guidance. India’s approach to AI governance is still developing through guidance from the Ministry of Electronics and Information Technology (MeitY). We track it and update this page when it changes our practice.
• European Union: GDPR, where it applies to personal data we process for a client.
• European Union: AI Act (Regulation (EU) 2024/1689), where a system is placed on the market, put into service or used in the EU, or its output is used there. The client, usually as provider or deployer, assesses with its own counsel how the Act classifies the system; we support that assessment by documenting how the system works.

Law in this area is changing quickly. This page is not legal advice, and clients should take their own advice on their obligations.

A question about this page or an AI system we built

Use the form on our Contact page.

A security issue, including prompt injection or data exposure

Use the form on our Contact page. Our responsible disclosure policy explains how we handle reports.

Your personal data (Grievance Officer)

Grievance Officer, NETSPHERE360 SOLUTIONS PRIVATE LIMITED, at the form on our Contact page. Our Privacy Policy explains your rights.

If you use a system we built for another organization, contact that organization first. It runs the service and is responsible for your data, and we will help it respond.

We review this page at least once a year, and whenever the law or our practice changes materially. Each change gets a new version number and date in the history below. A change to this page does not override what an existing client contract says.