AI Disclosure for Computer Science Research Papers

Computer science papers need AI disclosure in more places than the acknowledgments

Computer science researchers often use AI twice.

First, they study it. Then they use it.

That makes disclosure harder than it looks. A paper may introduce a new model, compare benchmark results, generate code with an assistant, use an LLM to label data, polish the final manuscript, and submit artifacts for review. One short sentence in the acknowledgments rarely explains all of that.

If you work in computer science, treat AI disclosure as part of your research record. You do not need to confess ordinary spell checking. You do need to tell readers when AI shaped the work they may try to inspect, reproduce, cite, or build on.

An [[AI Usage Card](/ai-disclosure-for-social-science-research/)](/) gives you a clean way to do this before submission. You can generate one for your paper, attach it as supplementary material, paste the text into your acknowledgment section, or keep it in your artifact package.

What counts as AI use in a CS paper?

Start with a plain question: did the tool affect the science, the software, the data, or the claims?

If yes, record it.

In computer science, AI use often shows up in places that journal templates do not name. You may use GitHub Copilot to draft a parser. You may ask ChatGPT to design ablation experiments. You may use Claude to summarize related work. You may use Gemini to translate interview notes. You may ask a local model to generate synthetic test cases.

Those tasks differ. A grammar edit does not carry the same risk as AI generated labels in a benchmark dataset.

The AI Research Tools and Disclosure guide gives a broader list of research tool categories. For CS papers, I would sort them into five buckets:

1. manuscript support
2. code support
3. data or benchmark support
4. model or experiment support
5. review, artifact, or release support

That last bucket matters. CS venues often ask for code, containers, model cards, datasets, scripts, and logs. If AI helped create those materials, readers need to know where.

ACM and IEEE do not treat every AI use the same way

Many CS researchers publish through ACM or IEEE, so their policies deserve close attention.

ACM updated its authorship policy on May 14, 2026. ACM states that authors must be identifiable humans, must make intellectual contributions, and must remain accountable for the work. Its FAQ allows generative AI tools under conditions, but draws a line between AI used in the research and AI used only for writing help. ACM says authors must describe AI use in the methods section when AI contributes to research design, data sources, experiments, code, model implementation, simulations, data analysis, validation, software deployment, or other parts of the research lifecycle that affect the paper's conclusions. ACM no longer requires disclosure for AI used only to assist with writing an ACM submission. (acm.org)

IEEE uses a different rule. IEEE says authors must disclose AI generated content in the acknowledgments section of any IEEE article, including text, figures, images, and code. IEEE asks authors to identify the AI system, name the sections that contain AI generated content, and explain the level of AI involvement. IEEE treats editing and grammar help as outside the main intent of the rule, though it recommends disclosure for that use. (open.ieee.org)

This difference creates a practical problem. A disclosure that fits one venue may look incomplete at another.

So do not write one sentence and reuse it everywhere. Keep a fuller record in an AI Usage Card, then adapt the short statement to the target venue. If you submit to ACM, separate research use from writing use. If you submit to IEEE, identify the system and the article sections.

For conference planning, see AI Conference Deadlines and Disclosure Planning and the guide to NeurIPS, ICML, and ACL disclosure. Those pages help when the paper moves from workshop to conference to journal.

Disclose AI use in code when it affects reproducibility

Code is not just support material in CS. It often carries the method.

If an AI tool writes or rewrites code that affects experiments, baselines, data cleaning, evaluation, simulations, or model training, document it. Readers do not need a diary of every autocomplete suggestion. They do need enough information to judge whether the code reflects your method and whether you checked it.

A useful code disclosure names the tool, the task, the files or modules affected, and your verification steps.

For example:

We used GitHub Copilot in Visual Studio Code to draft unit tests and helper functions in the preprocessing module. The authors reviewed all generated code, ran the full test suite, and manually checked the preprocessing outputs for a stratified sample of records.

That statement does not overdramatize the tool. It tells the reader where to look.

If AI helped generate experiment scripts, container files, or evaluation code, mention that too. Artifact reviewers care about the build path. If a hidden AI mistake changes a seed setting, dependency pin, or metric script, the result can waste someone else's afternoon.

The [AI Usage Cards Examples and Templates](/ai-usage-cards-examples/) page gives reusable wording for cases like code generation, language editing, and data analysis support.

Disclose AI use in datasets, labels, and benchmarks with extra care

Computer science papers often turn data into claims.

If you use AI to generate labels, clean records, summarize documents, remove duplicates, translate examples, produce synthetic data, augment samples, or filter benchmark items, put that in the methods section. Do not hide it in acknowledgments.

Readers need to know what the model saw, what humans checked, and where errors may enter.

A dataset disclosure should answer four questions:

What did the AI system do?

What input did it receive?

How did humans validate the output?

How can another researcher inspect or repeat the process?

If you already use dataset documentation, connect it to your AI disclosure. AI Usage Cards vs Datasheets for Datasets explains the difference: a datasheet describes the dataset, while an AI Usage Card describes the AI assistance used during the work. In CS papers, you may need both.

For synthetic data, say whether the synthetic examples entered training, evaluation, pilot testing, or only prompt development. Those uses carry different risks.

Disclose AI use in experiments and model development

AI assistance can enter the method before a single line of final text exists.

Maybe you used an LLM to propose baseline configurations. Maybe you used an agent to inspect failed runs and suggest parameter changes. Maybe a tool helped search through hyperparameter settings, write reward functions, generate prompts, or debug model behavior.

Those uses belong in the methods section when they affect results.

ACM's FAQ names several research lifecycle tasks that require detailed disclosure when AI plays a role, including experimental design, coding, model implementation, simulations, analysis, testing, validation, and reproducibility materials. (acm.org)

I would use a simple rule: if the reader would care about the step in a reproducibility review, disclose AI assistance for that step.

This matters for AI agent use. Agents can run tools, edit files, inspect errors, and make chained decisions. A sentence like "we used an AI assistant" tells reviewers almost nothing. If an agent touched the experiment pipeline, record the scope.

For more on agent based work, see Do Conference Papers Need to Disclose AI Agent Use?.

Writing assistance still deserves a careful record

Some venues no longer require disclosure for pure writing help. Some still ask for it. Some submission systems ask a yes or no question even when the author instructions sound more relaxed.

This is why a private record helps.

For writing assistance, record the tool, the date range, and the task. You do not need to store every prompt if you only used grammar edits. But if the tool drafted paragraphs, rewrote claims, summarized literature, or suggested citations, keep more detail.

A 2026 arXiv preprint on AI disclosure in CS research reported that top CS venue policies often remain underspecified. The authors surveyed 109 CS researchers and analyzed 13,867 disclosure statements from EMNLP 2025 and ICLR 2026. They found a mismatch between what researchers thought needed disclosure and what authors often disclosed, with writing assistance appearing often even when researchers considered research design more disclosure worthy. Treat that as a useful warning: do not let writing disclosure crowd out method disclosure. (arxiv.org)

If you need wording for general manuscript use, see How to Disclose ChatGPT Usage in Academic Papers and How to disclose Claude use in academic writing.

A practical disclosure structure for CS papers

For a CS paper, split the disclosure by location.

Put method relevant AI use in the methods section.

Put writing or presentation support in acknowledgments or in the journal's required declaration field.

Put code, data, prompts, and artifacts in supplementary material when the venue allows it.

Use your AI Usage Card as the source record. Then copy the relevant parts into the manuscript.

A good card should include:

• tool name and version, if known
• date or date range of use
• task
• affected paper sections, code files, data files, or artifacts
• human review steps
• outputs kept, changed, or rejected
• privacy or data handling notes

This structure also helps when you publish a preprint before conference review. arXiv announced in 2023 that authors should report material use of tools such as text to text generative AI in ways that match their field's methodology standards, and it reminds authors that each named author takes responsibility for the paper's contents. (blog.arxiv.org)

That responsibility sounds abstract until a fabricated citation slips into related work. Then it becomes concrete.

Example AI disclosure for an ACM style CS paper

Use this when AI affected the research method.

\section*{AI usage disclosure}
 
The authors used GitHub Copilot in Visual Studio Code during development of
the preprocessing scripts and unit tests for the artifact. The affected files
are \texttt{src/preprocess.py}, \texttt{src/filters.py}, and
\texttt{tests/test_preprocess.py}. The authors reviewed all generated code,
ran the full test suite, inspected preprocessing outputs for 200 sampled
records, and verified that the reported results did not change after manual
refactoring.
 
The authors used ChatGPT on 2026-07-18 to identify possible failure modes for
the evaluation protocol. The tool did not generate final experimental results,
tables, or claims. The authors selected the final protocol and take
responsibility for the work.

This version gives method detail. It names files and checks. It also says what the tool did not do.

If you used AI only for language edits in an ACM submission, check the current venue page. ACM's general FAQ no longer requires disclosure for writing assistance alone, but a specific conference may still ask for a declaration in the submission form. (acm.org)

Example AI disclosure for an IEEE style CS paper

IEEE asks authors to identify AI generated content, name the sections, and explain the level of involvement. This example follows that shape. (open.ieee.org)

\section*{Acknowledgment}
 
The authors used GitHub Copilot to generate initial drafts of helper functions
in the experimental code associated with Section IV. The authors reviewed,
edited, and tested the code before use.
 
The authors used ChatGPT to improve the clarity of sentences in Sections I and
VI. No experimental results, references, figures, or conclusions were generated
by the tool. The authors reviewed the final manuscript and take responsibility
for its content.

If the journal or conference uses a separate AI declaration field, paste the same content there. Keep the longer card with your records.

Example AI Usage Card entry for a CS artifact

An AI Usage Card can hold more detail than the paper itself.

\section*{AI Usage Card}
 
\textbf{Project:} Efficient graph sampling for dynamic networks
 
\textbf{AI tools used:}
\begin{itemize}
  \item GitHub Copilot, Visual Studio Code extension, used July 2026
  \item ChatGPT, GPT-5, used July 2026
\end{itemize}
 
\textbf{Use in code:}
GitHub Copilot drafted helper functions for data parsing, logging, and unit
tests. The authors reviewed and edited all accepted suggestions. The final
artifact includes tests for parser behavior, missing values, and graph size
checks.
 
\textbf{Use in experimental design:}
ChatGPT suggested possible ablation settings. The authors selected the final
ablations and ran all experiments.
 
\textbf{Use in writing:}
ChatGPT suggested sentence level revisions for the introduction and limitations
section. The authors accepted some edits after review.
 
\textbf{Human verification:}
The authors ran the complete reproduction script in a clean container, compared
outputs with saved result hashes, and manually inspected 50 sampled graph
records after preprocessing.

You can generate this structure at ai-cards.org and adapt it to your paper, thesis, artifact appendix, or repository.

Where to place the disclosure

Use the venue's wording first. Then add clarity.

For most CS submissions, choose among four locations:

The methods section fits AI use that affects data, code, experiments, models, analysis, or validation.

The acknowledgments section fits writing support, coding assistance, and general tool use when the venue asks for that placement.

The appendix fits longer records, prompts, validation notes, and artifact details.

The repository fits code related disclosure, especially when AI assistance affected scripts, tests, containers, or generated files.

If you prepare a journal submission after a conference paper, compare both policies. The AI Transparency Requirements for Journal Submissions guide covers that step. The AI Disclosure Policies by Major Journals page helps when your CS paper moves into a journal outside ACM or IEEE.

What not to do

Do not write "AI was used" and stop.

That sentence hides the only facts readers need.

Do not list ChatGPT as an author. ACM says authors must be identifiable human beings, and its FAQ says generative AI tools cannot be listed as authors. IEEE and other publishers follow the same basic logic: tools cannot take responsibility for the paper. (acm.org)

Do not bury method use in a vague acknowledgment. If AI shaped labels, code, experiments, or analysis, put it where readers expect method details.

Do not disclose only writing help while skipping code and data assistance. That pattern makes the disclosure look safe but leaves out the part that matters most for reproducibility.

A short pre-submission checklist

Before you submit, ask each coauthor these questions:

Did any AI tool help write, edit, translate, summarize, code, label, debug, analyze, visualize, or review the work?

Did AI output enter the manuscript, code, data, figures, tables, prompts, experiments, or artifact package?

Did humans check the AI output, and how?

Does the target venue ask for AI disclosure in the methods, acknowledgments, submission form, appendix, or repository?

Does your disclosure name the tool, task, affected material, and review steps?

If you cannot answer those questions, pause before submission. Open your lab notes, code history, prompt logs, and manuscript drafts. Reconstruct the record while people still remember what happened.

Then make an AI Usage Card.

The card keeps the record when the policy changes

CS disclosure rules change faster than publication cycles. A paper can start as a workshop abstract, become a conference submission, move to arXiv, and later become a journal article. Each venue may ask the AI question in a different way.

An AI Usage Card gives you one stable record underneath those forms.

Generate a card at ai-cards.org. Use it as your lab record, paste a short version into your manuscript, and attach the fuller version to your artifact or appendix when the venue allows it.

Good disclosure does not slow your paper down. It saves readers from guessing how the work came together.